Storage relocation follow-ups: handler isolation, finalize after move, orphaned copy on failed commit #1423

Low-severity follow-ups from the review of #1422 (storage visibility prefix). None of them blocked the merge.

1. One failing integration-event handler blocks the others for the same event. Handlers for FileStorageKeyChangedIntegrationEvent run in module order: Identity (100), Files (350), Catalog (600). If Files' DeleteSupersededObjectHandler throws (for example the store rejects a delete), Catalog's product-image URL rewrite is skipped on that attempt and waits for the outbox retry backoff. If the delete keeps failing until the event is dead-lettered, the rewrite never runs. Fix: publish a separate event for the durable delete, or isolate per-handler failures in the bus (check eventing.md: the inbox already dedups per handler, so per-handler retry may be the cleaner framework fix).
2. A finalize can fail after the file is already committed. FinalizeUploadCommandHandler moves an in-flight legacy upload after the finalize commit. If that copy fails, the client gets a 500 for a file that is actually Available, and retrying finalize returns 409. A public file is repaired on the migration job's next run; a private one stays at its legacy key. Fix: treat the move as best-effort there (log it, return success), or move before the commit.
3. A copy whose commit then fails leaves an orphaned, charged object. In FileStorageRelocator, if the copy succeeds and the transaction then fails, the new object is charged to quota and nothing cleans it up. Fix: on commit failure, remove the copy and refund its bytes.