fix(eve): degrade missing attachment bytes on resume instead of failing the turn

[serhiizghama]

Fixes #276. Resuming a durable session whose history contains an inbound file attachment fatally fails when the staging sandbox has been torn down between turns — an ephemeral backend means the bytes behind a historical eve-sandbox: ref are gone, and hydrateMessageContent threw on the missing read, so the turn ended in session.failed and the bot never replied.

Hydration now degrades a missing ref to a text part ("Attached file <path> (<type>) is no longer available in this session.") and logs a warning, instead of throwing. The run continues, and the model is told the attachment is unreachable rather than chasing a path that no longer resolves. I gave it a distinct message from the normal non-inlinable text reference on purpose — on resume the path really is gone, so pointing the model at it would just invite a failed read.

This only affects the resume case where the bytes are already missing; a freshly staged attachment in the current turn still hydrates as before.

Tests: rewrote the existing "missing file" case to assert the degrade (the leading text survives, the file ref becomes the unavailability notice, no file part reaches the model) and added a regression that stages an image into one sandbox and hydrates the resulting ref against a fresh one — the same shape as a resume after teardown — and asserts the turn survives. Reverting the fix fails both. Full attachment-staging integration + unit suites green, typecheck/oxlint/oxfmt/guard:invariants clean, changeset (patch).

[vercel]

@serhiizghama is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[ruiconti]

Thanks for this — the approach is right and we carried it forward in #507 with both of your commits cherry-picked, authorship and sign-off intact (they needed re-signing to satisfy the repo's signed-commit requirement, which a fork PR can't do).

#507 adds two things on top: a corrected root cause (the sandbox is never torn down — session sandbox names embed the deployment id, so any redeploy points the resumed session at a fresh sandbox; we traced the #276 incident to specific deploys) and a recovery hint in the model-facing text. There's also a follow-up plan in #509 to keep the bytes alive across deploys using sandbox drives.

Closing in favor of #507.