The everyday account: a new admin is led to an account apart from admin, and can still choose otherwise #803

Closes #596

A forge's admin is led, kindly and plainly, to make a separate everyday account for daily work. Using AI with admin stays possible, but only on purpose.

The path: a new admin signs in and lands on the home. One card says "Make your everyday account", with two sentences of why, and offers Make it (signs you in as the new account) or Keep using admin (recorded, not asked again). Next: the feed, as the everyday account.

Work in progress. This first commit is the link and the choice (core/everyday.ts). Next: the home card, the account pages naming the pair, the token confirmation for admins, the MCP note, tests and looks.

Ready for review (replaces the description above). Closes #596.

The path: a forge's admin signs in and lands on the home. One card asks them to "Make your everyday account", gives two sentences of why ("Admin can change everything here, including who can see what. Use it when you mean to; day to day, use an account that cannot break the forge."), and offers:

• Make it, with the username prefilled <admin>-me. It makes an ordinary account, links it to the admin, signs the person in as it, and lands on the home: "You are signed in as maria-me, your everyday account. Sign in as maria when you mean to change the forge."
• Keep using admin. The choice is recorded and the card goes. The account page keeps the way to make one later, without asking again.

What changed:

• core/everyday.ts: the pair, linked both ways in user_setting, and the recorded choice. No right is granted or removed.
• The home card (web/pages/everyday.ts), shown only to a site admin with no pair and no recorded choice. POST /settings/everyday and /settings/everyday/keep are admin only and same-origin.
• The account pages name the pair: "Your everyday account is …" on the admin's, "This is the everyday account of …" on the everyday account's.
• An admin's token is minted only on purpose. The tokens page shows admins one checkbox ("I mean to give this token admin … whatever holds it — an AI included — acts as admin") and refuses without it. POST /api/v1/tokens from a page's session needs adminConfirm: true for an admin. A token minted with the admin's password, typed by a person or a script, is already deliberate and is unchanged; requiring it there would touch some 30 test files.
• MCP initialize instructions for an admin's token add: "this token belongs to <admin>, the forge's admin, so what you do here acts as admin. Daily work belongs on <everyday>, their everyday account."

Removes: nothing. It adds one card for admins who have not chosen yet, and one checkbox for admins minting a token.

Tests: test/everyday.test.ts (8, in the gate). Refusing cases: a non-admin gets 403; cross-origin gets 403; a weak password or a taken name makes nothing; the token form without the tick and the session API without adminConfirm are refused. Then: the account made is ordinary, linked both ways and signed in; Keep is recorded and the account page still offers the form; the MCP note is there for an admin token and absent for anyone else. onboarding and edge-auth now tick and confirm for their admin users.

Full gate under the lock (main merged in): here-manifest and outsiders-switch fail on clean main too ("unverified", since #710). The two apps.test preview failures pass alone. crew.test "assignment" fails alone on main as well.

Looks (390 and 1280 px): the card at a form's width (34rem) above the feed on a desk and full width on a phone, with Make it and Keep using admin; after Make it, the green flash naming both accounts.