How this app runs itself: the crew and the ceiling, set from the studio #103

Pushed.

In studio mode, an app's Settings tab now leads to one page — src/web/studio/crew.ts (studioCrewSettings) — showing who is on the crew (role in studio's words, brief, add/change-role/remove) and how it runs itself (assisted/autonomous, today's spend against the ceiling, slots in use, paused-and-why), all sourced from autonomyStatus/listCrewRoles exactly as the app page already computes them. Every form posts to the existing crewAdd/crewRemove/crewRoleUpdate/autonomySettingsUpdate actions and routes — no new route, no new authorization logic. Facts render for anyone who can write to the repo (canSeeOwnerFacts, matching the app page's privacy rule); the forms themselves render only for an admin, since that's what those actions already require, so a writer-but-not-admin sees the same facts with no controls that would just be refused. A non-writer gets a plain notice, a non-reader gets the forge's 404. ?mode=dev still renders dev's full settings shell unchanged, which keeps its own Crew/Autonomy tabs. The app page's "Change" links now point at this one page instead of dev's split routes.

Left out: I did not add a "direction" field to this page (the planner's standing instruction) — it's preserved via a hidden input so saving autonomy settings from here never clears it, but editing it stays a dev-only affair, per the issue's scope note. docs/STUDIO.md documents where this lives. test/studio.test.ts covers: a writer sees the crew and ceiling with controls; a reader sees facts with no controls and a non-reader gets 404; a reader's POST is refused; a role change posted from this page lands exactly where dev's own page redirects to; ?mode=dev is untouched.

Closes #61