feat(*): raise the attachment upload ceiling to 100 MB

[arelchan]

Summary

A 26 MB deck dropped on the composer was refused. The upload ceiling stood at 25 MB, a number it never chose: it was the file viewer's, adopted when fs.upload landed beside it. The viewer picked 25 MB because no renderer in the page does anything useful past that size, which is not a reason that applies to an upload.

An upload answers a different question. It only has to land a path in the workspace -- a non-image attachment is named to the model and never read into the message -- so the bytes exist to reach the disk, not a renderer. This raises MAX_UPLOAD_BYTES to 100 MB and leaves MAX_VIEW_BYTES at 25 MB. A file between the two can therefore be attached and not previewed; the constant's comment now states that instead of implying the two move together.

frame_ceiling_for_upload derives the WebSocket frame ceiling from this constant, so the base64 expansion that once capped attachments at roughly 3 MB cannot come back from raising the number. The page's mirrored copy moves with it.

The ceiling that remains is memory, not policy: one upload at this size costs the gateway the frame, the JSON string parsed out of it and the decoded bytes at once, and the parse holds the event loop while it runs. A much larger limit wants the streamed HTTP upload path, not a bigger number here. That is left for its own change.

This also sweeps four comments that stated 25 MB as the current ceiling; they name the constant now. The three describing the old 3 MB frame bug keep their number, because they report what was true then.

Deliberately out of scope: the composer and the subagent page measure an attachment after base64-encoding it rather than before, so an oversized file is read whole and thrown away while the tab blocks. uploadRefusalBySize already exists for the pre-encode check and the knowledge page uses it; wiring the other two callers crosses the composer source contract, so it belongs in its own change.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

Server side, end to end at the size that was refused (26.2 MB), through the real aiohttp WebSocket and the real method:

• a frame carrying that file as base64 comes back answered, not disconnected
• fs_upload accepts it and the bytes land in uploads/ at the right size
• MAX_UPLOAD_BYTES + 1 is still refused, with 100 MB in the message

Those three ran as a throwaway probe and are not added to the suite. The committed guard is test_the_frame_ceiling_can_carry_the_largest_upload_the_method_accepts, which reads the constant rather than a literal and so keeps the two limits coupled at any value.

Gates run locally, after rebasing onto github/main at 82a51d8:

uv run pytest tests/test_rpc_transport.py tests/test_rpc_files.py tests/test_rpc_console.py -q
  172 passed
make lint-python     All checks passed / 1625 files already formatted
make lint-imports    clean
make lint-deps       Success! No dependency issues found.
make lint-types      All checks passed!
npm run gen:check --prefix ui-web    generated.ts matches the contract (178 methods)
npm run type-check --prefix ui-web   clean
npm test --prefix ui-web             108 files, 1837 tests passed
node ui-web/scripts/check-page.mjs             OK
node ui-web/scripts/count-shared-globals.mjs   OK
node ui-web/scripts/check-css.mjs              OK
node ui-web/scripts/check-class-namespace.mjs  OK

Page side, in a real browser against a raven serve built from this branch, on an isolated RAVEN_HOME:

• a 26.1 MB .pptx dropped on the composer attaches: the chip goes solid at "26.1 MB" with no failure note, and the file lands in <workspace>/uploads/ at exactly 27,400,000 bytes with its non-ASCII name intact
• a 105 MB file is refused, and the note names the new ceiling ("105.0 MB", "100.0 MB"), so the limit was raised rather than removed and the message follows the constant

The drop was a synthesized DragEvent: it exercises the page's own drop handler and the whole upload path, but not the operating system's part of the drag.

No user-facing docs name this ceiling. The one doc mention of 25 MB is the viewer's render cap in docs/specs/2026-08-26-desk-deliverables-shelf.md, which this change does not touch.

• Relevant tests pass locally
• Relevant lint / type checks pass locally
• User-facing docs or screenshots are updated when needed

Risk

Behaviour change: an attachment up to 100 MB is now accepted where 25 MB was the wall. Per upload the gateway holds the frame, the parsed JSON string and the decoded bytes at once -- roughly 370 MB peak for a maximal one -- and the JSON parse blocks the event loop for a second or more. Single-user desktop use absorbs that; a shared gateway taking concurrent uploads would feel it.

Security: the route is unchanged. fs.upload is reachable only over an authorized socket, so the larger allocation is available to the signed-in local reader and to nobody new. What grew is how much memory that reader can ask for in one call.

A file between 25 MB and 100 MB can be attached and not opened in the viewer, which still refuses past MAX_VIEW_BYTES.

Rollback: revert the two constants. Nothing persists, no schema or contract moved, and frame_ceiling_for_upload recomputes from whatever the constant says.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[gloryfromca]

No blockers; this can merge as far as I am concerned.

Reviewed github/main...HEAD at 702ca543e00a. I found no issue worth raising.

Coverage included the repository rules in AGENTS.md / CLAUDE.md and CONTEXT-MAP.md; the complete diff; the server upload enforcement and WebSocket frame sizing; the browser-side mirrored limit and the knowledge, composer, and subagent upload callers; the relevant history; backward compatibility of retaining the 25 MB viewer ceiling; the UI-to-runtime RPC boundary; and whether tests were weakened. The test edits only remove stale literal wording, while the existing arithmetic transport contract still derives from MAX_UPLOAD_BYTES. The known encode-before-refusal behavior in two callers predates this change and is not made incorrect by the new ceiling.

Independent verification:

• uv run pytest tests/test_rpc_transport.py tests/test_rpc_files.py tests/test_rpc_console.py -q: 172 passed
• npm test --prefix ui-web: 108 files, 1837 tests passed
• npm run type-check --prefix ui-web: passed
• the check-source-language command from the Makefile, invoked directly because make is unavailable here: passed
• git diff --check github/main...HEAD: passed

At posting time all completed GitHub checks pass; only coverage gates is still pending.