… and remote URLs (#5092)

* feat(providers): support large agent-block attachments via Files APIs and remote URLs

Agent-block file uploads were inlined as base64 with a hard 10MB cap. Files
above the threshold now use each provider's native large-file path:

- OpenAI / Gemini: upload to the provider Files API, reference by file_id/uri
- Anthropic: GA url content-block source (no Files API beta, no upload)
- OpenRouter/Groq/Together/Baseten/xAI/vLLM: remote signed URL in image_url/file
- Limits live per-provider in models.ts; the agent block + /models page reflect them

Files <=10MB keep the identical base64 path (zero regression). Server-only file
handles are stripped from untrusted input to prevent SSRF.

* fix(providers): clear forged file handles for inline providers too

attachLargeFileRemoteUrls early-returned for inline-strategy providers before
clearing server-only handle fields, so a forged remoteUrl on an inline-provider
file could still reach a builder (e.g. buildOpenAICompatibleChatContent for
mistral/ollama). Clear the handles for every provider before the strategy check.

* fix(providers): correct OpenAI expiry serialization and Anthropic large-text-doc handling

- OpenAI upload now uses the SDK (client.files.create) so expires_after is
  serialized as a real nested object; the prior expires_after[anchor] bracket
  FormData keys were ignored by OpenAI's server, leaving files un-expiring.
- Anthropic url document source only supports PDFs/images; large non-PDF text
  docs now throw a clear error instead of emitting an unsupported url source.
- Warn when an oversized file can't be sent because cloud storage is unavailable.

* fix(providers): harden large-file path (SSRF fetch, ceiling gate, per-file UI limit)

- Download files for OpenAI/Gemini uploads via validateUrlWithDNS + IP-pinned
  fetch so a forged URL can't reach internal addresses (covers all callers).
- Reject files above the provider ceiling before downloading/uploading.
- UI now validates each file against the provider's per-file ceiling instead of
  summing all files against it, matching server-side per-file validation.
- Lower Anthropic ceiling to 50MB (documented 32MB request cap / page limits).

* refactor(providers): read files-api upload bytes via storage SDK

Read OpenAI/Gemini upload bytes through downloadFileFromStorage instead of
HTTP-fetching the presigned URL. Removes any server-side URL fetch (no SSRF
vector) and works with internal object storage (e.g. self-hosted MinIO), which
an IP-pinned URL fetch would have blocked.

* docs(providers): clarify files-api bytes are read from storage at upload time

* fix(providers): enforce access checks and strip forged ids in the upload path

uploadLargeFilesToProvider runs on raw request messages for every caller (incl.
the internal providers passthrough), so harden it independently of the agent path:
- verifyFileAccess on each file's storage key before reading its bytes, so a forged
  key can't exfiltrate another user's file.
- clear any inbound providerFileId/providerFileUri up front (legit ids are only set
  by the upload itself), so a forged id can't reference a file in a hosted account.

* fix(providers): resolve UI attachment limit with the same model->provider helper as execution

The file-upload control imported getProviderFromModel from @/providers/models, but
the execution path and every other consumer use the one in @/providers/utils (runtime
registry + reseller patterns). Align the UI so its size cap can't disagree with
server-side validation for reseller or dynamically-listed models.

* test(providers): add new models.ts exports to provider mocks

attachments.ts now reads getProviderFileAttachment / INLINE_ATTACHMENT_MAX_BYTES
from @/providers/models; the provider unit tests that fully mock that module need
both exports or attachments.ts fails to load.

* fix(providers): guard Gemini upload response name before polling

ai.files.upload returns name as string | undefined; guard it (instead of an
as-string cast) so a missing name surfaces a clear error at the upload site
rather than an opaque files.get failure on the first poll.

* fix(uploads): type the file-handle key list so omit preserves UserFile fields

The 'as const' readonly tuple widened omit's K to all keys, collapsing
Omit<UserFile, K> to {} and failing the production build's type check. Declare
the array as Array<keyof handle fields> so K is the precise literal union.

* refactor(providers): run handle-clear + URL-mint in executeProviderRequest for all callers

Move attachLargeFileRemoteUrls out of the agent handler and into
executeProviderRequest (right before uploadLargeFilesToProvider), so every entry
point — including the internal providers passthrough — clears forged handles and
mints/access-checks large-file URLs uniformly. The agent handler now only hydrates
base64; its missing-file guard exempts large files (resolved downstream).

* fix(azure-openai): guard optional attachment dataUrl in inline image part

PreparedProviderAttachment.dataUrl is now optional (large files carry a handle
instead); azure-openai builds chat content inline and assigned it directly to a
required url field, failing the production build's type check.

* fix(providers): upload OpenAI files via multipart and fix Buffer Blob part

The installed openai SDK (4.104) does not type expires_after on files.create, so
upload via POST /v1/files directly with the documented expires_after[...] form
fields (gives the file an auto-expiry). Also wrap the storage Buffer in a
Uint8Array for the Blob, which the production build's stricter lib types require.

These two type errors were masked locally because tsc was OOMing silently without
the type-check script's --max-old-space-size flag.

* fix(providers): forward userId from the providers API to executeProviderRequest

Large-attachment prep now needs request.userId for presigned URLs and access
checks; the authenticated providers proxy has auth.userId but wasn't passing it,
so oversized attachments failed for logged-in callers. Forwarding it makes large
files work there and keeps the access check (verifyFileAccess) intact.

* fix(providers): fail clearly when a large attachment has no cloud storage

The doc claimed a base64 fallback that doesn't exist — above the inline cap there
is no base64, so without cloud storage the file previously reached the builder and
died with a generic read error. Throw a clear 'requires cloud file storage' error
at the point of detection and correct the doc.

…turn options in view (#5094)

* fix(chat): align scrollbar/keyboard detach with wheel/touch re-engage threshold

The onScroll detach branch set only stickyRef.current = false, leaving
userDetachedRef false, so a scrollbar-drag or keyboard detach kept the lenient
30px (STICK_THRESHOLD) re-engage threshold instead of the strict 5px
(REATTACH_THRESHOLD) used after wheel/touch. A programmatic virtualizer re-pin
landing within 30px could then snap autoscroll back on right after the user
deliberately scrolled away. Reuse the detach() helper so all detach paths set
userDetachedRef consistently.

* fix(chat): keep end-of-turn options in view after streaming

When a stream ends, the suggested-follow-up options and the actions row (gated
on !isStreaming) mount, but the virtualizer's getTotalSize — which drives the
scroll container's scrollHeight — only catches up a frame or two later via its
ResizeObserver. The single scrollToBottom() on effect teardown therefore landed
on a stale, too-short bottom and the options were clipped behind the input.
(Pre-virtualization this worked because scrollHeight reflected the new rows
immediately.)

Extract the rAF follow loop already used for CSS height animations into a shared
followToBottom(window) helper and run it for a short settle window on teardown,
so the bottom is chased until the virtualizer re-measures. The follow is
self-interrupting — height growth leaves scrollTop where we put it, while a user
scroll moves it up, so it bails the instant the user scrolls and never fights a
real gesture even with listeners torn down.

…ings (#5095)

A live-doc audit of the merged large-file feature found two ceilings that were
higher than the provider actually accepts:
- Gemini: 100MB -> 50MB. Gemini hard-caps PDFs at 50MB, so a 50-100MB PDF passed
  our gate, got uploaded + polled, then failed at generateContent. 50MB respects
  the documented limit and is more memory-safe.
- vLLM: 50MB -> 25MB. vLLM's default image-fetch timeout is 5s; a 50MB remote
  fetch routinely exceeds it. 25MB aligns with that reality and matches Baseten
  (the other vLLM-backed provider).

* fix(realtime): re-check workspace role on mutating socket events

* address comments