[njoubert-cleverage]

Description

Fixes #228.

Regression of 3.4 (#209): any input located directly in the upload directory was deleted after the execution, even when given by its path (an API user could delete a file of another user waiting in the queue; schedules and default inputs lost their reference file), the file was also deleted when the execution failed (a retried message ran without its file), and the file written for a request rejected by the HTTP API (422) was never deleted.

• ProcessExecuteMessage gets an optional deleteInput argument (false by default, positional compatibility kept; a message serialized by 3.4 is read as false). Only LaunchAction and the HTTP API set it, for the file they have just written (the HTTP value resolver flags it with a request attribute, not in the deserialized model, so that a client cannot set it). The upload directory check of UploadedFileManager is kept as defense in depth; cleverage_ui_process.delete_uploaded_files: false still disables the deletion.
• In a Messenger worker, a failed message keeps its file while it will be retried or when it is sent to a failure transport (messenger:failed:retry), as SendFailedMessageToFailureTransportListener decides depending on the Symfony version: new internal UploadedFileSubscriber (worker events) and UploadedFileSubscriberPass (failure transports). Outside of a worker (sync transport, unrouted message), the handler deletes the file after a successful or failed execution.
• The file uploaded with a request rejected by the HTTP API (422) is deleted.
• The messages queued by 3.4 have no flag: their file is no longer deleted by the worker (CHANGELOG, documentation).

Requirements

• Documentation updates
  • Reference
  • Cookbooks
  • Changelog
• Unit tests

Breaking changes

None: a file given by its path is no longer deleted (regression of 3.4); the changed signatures (LaunchAction::dispatch(), ProcessExecuteHandler, ProcessExecuteController) are internal.

🤖 Generated with Claude Code