[backport camel-spring-boot-4.22.x] CAMEL-24593: platform-http-starter - delete multipart uploads when the exchange is done

[Croway]

Update: Rebased onto the now-merged CAMEL-24577 (#1959), which added a "Path variables" section
to this same doc file and touched SpringBootPlatformHttpBinding.java (reading path placeholders
from ServletRequestPathUtils.parse(request) instead of getRawPath(request)). This resolves the
resulting merge conflict; both fixes coexist in SpringBootPlatformHttpBinding.java and in
platform-http.adoc ("Path variables" and "File uploads" sections are both kept). See the updated
"Depends on" and "Verification" sections below for details.

Cherry-pick of #1934 onto camel-spring-boot-4.22.x.

Original PR: #1934 — platform-http-starter - delete multipart uploads when the exchange is done
JIRA: CAMEL-24593

What it fixes

SpringBootPlatformHttpBinding.populateAttachments() copies every accepted multipart upload out of
the servlet container into the servlet temp directory, and uses that copy as the attachment
DataSource and, for a single upload, as the Path message body and the CamelFilePath header.
Because MultipartFile.transferTo() moves the container's part file, the container's own
end-of-request cleanup can no longer find it, and nothing in the starter deleted the copy either —
every accepted upload stayed on disk for the life of the process.

The copy was introduced in CAMEL-21461 so the body can be a Path and the attachment stays readable
after the servlet request has completed, which is a good reason to own the file — but owning it means
being responsible for removing it too. The other HTTP bindings don't have this problem:
camel-http-common reads the part through the container-managed file (which the container deletes),
and camel-platform-http-vertx already defaults deleteUploadedFilesOnEnd to true.

The binding now tracks the temp files it created for a request and registers a Synchronization
via ExchangeExtension.addOnCompletion that deletes them once the exchange is done being routed —
after the HTTP response has already been written, so nothing currently reading the files is
affected. A new opt-out property, camel.component.platform-http.server.delete-uploaded-files-on-end
(default true), mirrors the Vert.x option, for routes that hand the file to something that reads it
after the exchange completes.

This is a resource-leak fix only: no default-behavior change to existing routes, and existing public
constructors are unchanged.

Depends on CAMEL-24496, rebased onto CAMEL-24577

This cherry-picks onto camel-spring-boot-4.22.x on top of CAMEL-24496 (#1953). Since this branch
tracks main much more closely than 4.18.x, the original cherry-pick applied almost cleanly:
SpringBootPlatformHttpAutoConfiguration.java, SpringBootPlatformHttpEngine.java,
SpringBootPlatformHttpConsumer.java, SpringBootPlatformHttpBinding.java and the aggregated
docs/spring-boot/modules/ROOT/pages/starters/platform-http.adoc page all auto-merged with no
manual intervention, and coexist correctly with CAMEL-24496's filename-whitelist checks (which run
earlier in populateAttachments(), before this fix's cleanup registration).

At the time this PR was opened, the only conflict was in the module-owned
components-starter/camel-platform-http-starter/src/main/docs/platform-http.adoc: main's diff
context included a "Path variables" section from CAMEL-24577 (percent-decoded path placeholders),
which was not yet merged into this branch (still open as #1959 at the time). That section was left
out so as not to pull in unmerged content from a different ticket.

CAMEL-24577 (#1959) has since been merged into camel-spring-boot-4.22.x, which made this PR
conflict with the new base (same doc section reappearing, needing both kept). This branch has been
rebased onto the current tip: the "Path variables" section is restored alongside this PR's "File
uploads" section in platform-http.adoc, and SpringBootPlatformHttpBinding.java now carries both
fixes side by side — CAMEL-24577's path-variable read (ServletRequestPathUtils.parse(request)) and
this PR's upload-cleanup tracking/registration are in different parts of the class and did not
actually overlap on any line.

Verification on this branch

• After the rebase onto the merged CAMEL-24577, the only remaining conflict was the doc section
  described above; resolved by keeping both the "Path variables" and "File uploads" sections. The
  Java file merged cleanly (no conflict markers), and its diff against the new base shows only this
  PR's own changes.
• Built with ./mvnw -DskipTests -Dfastinstall install -pl components-starter/camel-platform-http-starter -am
  (parent/camel-version and the ~535 hardcoded org.apache.camel/org.apache.camel.maven
  SNAPSHOT entries in tooling/camel-spring-boot-dependencies/pom.xml temporarily repointed to the
  released 4.22.0 for local resolution, reverted afterwards) — succeeded.
• Ran ../../mvnw verify in components-starter/camel-platform-http-starter: 134 tests total (0
  failures, 0 errors, 2 pre-existing skips), including both CAMEL-24577's path-variable tests
  (SpringBootPlatformHttpPathVariableTest, SpringBootPlatformHttpBindingPathVariableTest) and
  CAMEL-24593's upload-cleanup tests (SpringBootPlatformHttpUploadCleanupTest,
  SpringBootPlatformHttpUploadCleanupDisabledTest) passing.
• Confirmed git diff origin/camel-spring-boot-4.22.x --stat only shows the 11 files touched by
  this PR's own commit (temporary pom.xml/BOM/catalog build artifacts reverted before pushing).

Claude Code on behalf of Federico Mariani