The studio is the default front door #28

DEFAULT_MODE in src/web/mode.ts is dev, with the comment "until the studio has earned the front door"; src/http/context.ts:29 already documents the opposite ("studio when unset"), and src/web/pages/site.ts:673 is written as though studio were the default. Make it so: a browser with no cookie lands in the studio.

This is the direction's headline and it is one constant plus its consequences. Land it after the studio app page shows every preview and after New app lands on a page that shows the app coming alive — a front door that cannot show you a preview is not one.

Acceptance

• [ ] DEFAULT_MODE is studio; a request with no forge_mode cookie gets the studio home, and the module comment says what is now true.
• [ ] ?mode=dev still switches and sets the cookie, and ?mode=studio does the same in the other direction — the escape hatch works both ways, as a link someone is given must.
• [ ] A person with no apps does not land on an empty page: the studio home's empty state names New app and offers the repositories list in one click.
• [ ] Long app descriptions do not run the studio home's rows to five lines — a row's description is one clamped line (trevato/books and trevato/circuit are the cases; both read as paragraphs today).
• [ ] Deep links are unchanged in both modes, and every page that is dev-only still answers under the studio cookie.
• [ ] docs/STUDIO.md and README.md say studio is the default and how to leave it; src/web/mode.ts's comment no longer says dev is.
• [ ] test/studio.test.ts: a signed-in request with no mode cookie gets the studio home; ?mode=studio sets the cookie; ?mode=dev still wins for that browser. Whatever in test/web.test.ts assumed the dev home by default is updated to ask for it by cookie — the test was right about dev, not about the default.

Files I expect to change

src/web/mode.ts, src/http/server.ts (the ?mode=studio side), src/web/pages/studio.ts (the empty state and the row clamp), test/studio.test.ts, test/web.test.ts, docs/STUDIO.md, README.md.

Risks

• The blast radius is the test suite. Every web test that fetches / without a cookie changes meaning; the check in forge.json runs test/web.test.ts and test/studio.test.ts together, so run the whole command before pushing, not one file.
• The TUI and the API are unaffected and must stay that way — mode is a browser cookie, nothing else.
• A first-time visitor with nothing to see is the worst case for a front door; the empty state is the acceptance criterion that carries it.

Who

Scout — small, exact, and the whole check green before it lands.

Two of this issue's acceptance lines — the one-line clamp on the home's app rows, and the empty state that names New app and the repositories list — do not depend on anything and are now #69, so they can land while this one waits on #13. What is left here is the flip itself: DEFAULT_MODE, the symmetric ?mode= switch, the test suite's assumptions about the default home, and the two documents that say which mode is the default.

Unblocked, and ready now. Its three recorded blockers (#25, #34, #42) are all closed, and I have removed the link to #13: the reason I wrote it — a front door that cannot show you a preview is not one — is satisfied in main, where the app's studio page draws every open pull's preview (previewsPanel, src/web/pages/studio.ts:799) and keeps itself current (#53, #64). #13 is about where the New app form lands, which is a separate journey from which home a browser with no cookie gets, and it has been stuck behind a conflicted pull for a day.

The two acceptance lines that moved to #69 (the row clamp and the empty state) are still there; the rest of this issue is the flip, ?mode=studio made symmetric, and the tests and docs that follow it.