The client list: /forges shows every forge the owner sent, for whom, and whether they claimed it #776

Pillar: P4 Forge in a link (#590). One run. Split from #601, which became the starter budget (pull #765).

Outcome. One page lists every forge the owner has sent: for whom, which apps, the link, whether they have logged in, and what has happened since.

The path: the owner, from the feed's header or the "+ New forge" page, wants to know how the forges he sent are doing. The primary action per row is to open its link. Next: the child, or back to the feed.

Acceptance.

• [ ] Spawn input takes for (free text, at most 200 characters: the person, client or organisation). It is kept in the parent's spawn ledger.
• [ ] /forges (admins of the parent only): one row per child from the ledger, with name, for whom, apps sent, link, claimed or not, and last activity.
• [ ] Claimed and last activity come from a small public GET /api/v1/forge on the child ({claimed, lastActivityAt}, nothing else, 404 on a forge that was not spawned), fetched with a short timeout. "Unknown" when unreachable.
• [ ] MCP forges lists the same rows.
• [ ] Refusing tests: a non-admin of the parent gets 404 on /forges, and GET /api/v1/forge on a forge that was not spawned is 404.
• [ ] Done means reachable: the page, the MCP tool, tests, and looks at phone and desktop widths.

Start from: src/actions/spawn.ts (listChildren, the ledger), src/spawn/door.ts, src/spawn/claim.ts (spawnedOrg), src/http/api.ts, src/http/mcp.ts.

Must not touch: the release workflow, the chart, other repositories.