fix: deduplicate files by destination before sandbox validation

[proseer-lars]

Problem

Some callers (e.g. LibreChat) send the same file more than once per exec request when a user re-uploads a file in the same conversation. The sandbox's validateExecuteFiles() rejects duplicate destinations, which causes every tool call in that conversation to fail with:

Error from sandbox: [bad_request] files contains duplicate destination "filename.pdf"

This surfaces to the end user as a confusing "the code-execution sandbox appears to be down" error — the sandbox itself is healthy, it's just rejecting the duplicate file list.

Fix

Add deduplicateFilesByDestination() in getJob() before final validation. It bounds and validates every raw entry, then keeps the latest file at each exact destination so re-uploads replace older copies. It preserves original implicit file${index}.code destinations across compaction, matching signed manifest claims, and emits one aggregated warning when duplicates are dropped.

validateExecuteFiles() still rejects duplicate and ancestor-conflicting destinations (e.g. results vs results/out.csv) when called directly. Its per-file validation is shared with the dedup step so malformed entries cannot be concealed by a later duplicate.

Test plan

• Existing tests pass (validateExecuteFiles still rejects duplicates when called directly)
• New tests cover latest-wins ordering, original-index implicit names and manifest scope, malformed duplicates, raw-count limits, and the /execute route
• Focused Bun tests: 36 passed across file validation, request route, and execution manifest
• Follow-up commit has not been deployed; the original duplicate-destination fix was reported by the author as production-verified (self-hosted LibreChat + code-interpreter)
• tsc --noEmit still reports diagnostics in unrelated pre-existing API files; no diagnostics in the three changed files