Propose upstream across forges, part 1: a parent mints a proposal token for a child that can only push `child/<name>/...` branches and open pulls #2176

Replaces #1831 (parked twice). Pull #1882's token narrowing passed security review on its last head. The one remaining ask: a migration comment claims already-orphaned tokens are removed, but the migration only creates the trigger. Either delete them safely or delete the claim.

Done looks like:

• [ ] A writer of a parent repository mints a proposal token for one named child (in src/core/tokens.ts' shape, sealed). It can push only branches under child/<name>/ over HTTPS and open pulls from them. A push to the default branch or any other ref is refused with one line. Every other API is a 403, enforced before any handler runs.
• [ ] At the parent, a pull opened with it names the child and its origin, escaped wherever it renders. Proposals are rate-limited per token, and a body over the size limit is refused.
• [ ] Deleting the child or the repository removes its tokens (trigger). Every comment in the migration says only what the migration does.
• [ ] Tests in a file named in GATE: refused on main, refused outside the namespace, hostile branch names (child/x/../../main, control characters) refused, oversize body refused, rate limit enforced, non-pull API 403.

Files: src/core/tokens.ts, src/git/*, src/http/api.ts, a migration, test/proposal-token.test.ts, scripts/gate.ts. Risk: a gate that fails open; every token request must go through one gate.