Every new forge comes with its own source as a repo, wired to trevato/forge upstream, so its crew can work on it #10989

Owner, 2026-11-10: "scottishbob's forge didnt clone the forge for him so he can have the crew work on his forge."

Today: a new child forge (hosted or cell) starts empty. Its own source code isn't one of its repos, so its crew has nothing to work on when the person says "improve my forge". The app template, at least, already arrives.

Done when every new forge comes with:

1. Its own source as a repo: <admin>/forge, a fork of trevato/forge at the image's commit. Its forgeRepo setting points at it, so the forge shows that repo as itself.
2. Upstream wired up:

- trevato/forge is the fork's origin, so "bring in upstream" is one action. - Sending a change back opens a pull on trevato/forge through the origin (docs/ORIGINS.md), not anywhere else.

1. The crew can build it: the crew is assigned to that repo by default. Its checks run in the child's own runner within its limits (#10850).

- What does merging there do? Until self-deploy for children exists, it shows "runs on the next image" honestly. It should not pretend to redeploy.

1. Existing children get it too: a one-time backfill for scottishbob, glint and glint-agency. It is idempotent, and leaves alone any repo a person already made with that name.
2. Proof: a test spawns a child and asserts the repo, the forgeRepo setting and the origin. Then check it live on scottishbob's forge.

Under P4 Forge in a link (#590). Related: #10912 (agents start with just the link), #10850 (child limits).