Auto mode with a direction and no planner does nothing, silently: a migrated repository gets a planner or says why not #7772

Auto mode with a direction on a repository whose crew has no planner now gets a planner, and the autonomy card says why when a saved direction has no direction issue yet. The new test and the neighbouring autonomy and crew-loop suites pass, bun x tsc --noEmit is clean, and design-lint is clean. I did not run the full suite; the forge's check does that on push.

What changed

• New module src/crew/planner.ts.

- ensurePlanner returns the crew's planner. If there is none, it adds the agent that plans on the most other repositories on the forge, sets that agent's role to planner, and emits crew.added. - directionStall returns the reason a saved direction has no direction issue, or null when nothing is wrong.

• planIfThin in src/crew/autonomy.ts. Before it returns "no planner on the crew", it calls ensurePlanner. The next planning turn then opens the direction issue and assigns it to the planner, with no further step. This also rescues repositories already stuck this way, such as pixel-plays, without anyone re-saving the direction.
• The Direction field in src/web/studio/crew.ts. It shows #direction-stall whenever autonomy is on, a direction is saved and no direction issue exists. It says either "No planner is on the crew, so nothing will act on this direction. The next planning turn adds one if the forge has a planner to lend; otherwise add one under Crew." or that the planner opens the issue at the next planning turn.
• test/planner-lent.test.ts. The setup mirrors pixel-plays: a repository whose crew is one builder, in autonomous mode with a direction. The test checks the stall message, then that driveRepo returns "planned", the planner joins the crew, and the direction issue is assigned to it.

What I chose not to do

• No planner anywhere on the forge. If no other repository has a planner, nothing is lent. The tick logs "no planner on the crew" and the card explains it. That case still needs a person to add a planner under Crew.
• Saving a direction. It does not add the planner at save time; the next planning turn does. This is the simpler of the two options the issue allowed. I did not add a button either, because the planner is added automatically.
• Migration. I left it untouched, so it stays as fast as before.
• Issue page. I read "the issue's page" as the autonomy card, where the direction is written. I did not add anything to the individual issue page.

Closes #7637

Auto mode with a direction on a repository whose crew has no planner now gets a planner, and the autonomy card says why when a saved direction has no direction issue yet. The new test and the neighbouring autonomy and crew-loop suites pass, bun x tsc --noEmit is clean, and design-lint is clean. I did not run the full suite; the forge's check does that on push.

What changed

• New module src/crew/planner.ts.

- ensurePlanner returns the crew's planner. If there is none, it adds the agent that plans on the most other repositories on the forge, sets that agent's role to planner, and emits crew.added. - directionStall returns the reason a saved direction has no direction issue, or null when nothing is wrong.

• planIfThin in src/crew/autonomy.ts. Before it returns "no planner on the crew", it calls ensurePlanner. The next planning turn then opens the direction issue and assigns it to the planner, with no further step. This also rescues repositories already stuck this way, such as pixel-plays, without anyone re-saving the direction.
• The Direction field in src/web/studio/crew.ts. It shows #direction-stall whenever autonomy is on, a direction is saved and no direction issue exists. It says either "No planner is on the crew, so nothing will act on this direction. The next planning turn adds one if the forge has a planner to lend; otherwise add one under Crew." or that the planner opens the issue at the next planning turn.
• test/planner-lent.test.ts. The setup mirrors pixel-plays: a repository whose crew is one builder, in autonomous mode with a direction. The test checks the stall message, then that driveRepo returns "planned", the planner joins the crew, and the direction issue is assigned to it.

What I chose not to do

• No planner anywhere on the forge. If no other repository has a planner, nothing is lent. The tick logs "no planner on the crew" and the card explains it. That case still needs a person to add a planner under Crew.
• Saving a direction. It does not add the planner at save time; the next planning turn does. This is the simpler of the two options the issue allowed. I did not add a button either, because the planner is added automatically.
• Migration. I left it untouched, so it stays as fast as before.
• Issue page. I read "the issue's page" as the autonomy card, where the direction is written. I did not add anything to the individual issue page.

Auto mode with a direction and no planner on the crew now gets a planner at the next planning turn, and the saved direction's stall reason is visible in the studio, the terminal and the MCP. The new tests, the neighbouring autonomy, crew-loop, MCP-vision, TUI-vision and MCP-docs suites, bun x tsc --noEmit and design-lint all pass. I did not run the full suite; the forge's check does that on push.

What changed

• Planner lending (src/crew/planner.ts, called from planIfThin).

- Candidates are limited to agents that already plan on the same owner's other repositories. An agent seen only on someone else's repository is never lent. - The agent joins through addToCrew with the autonomy actor as the caller. That is the same admin and verified checks as a manual add, and it emits the same crew.added event. If the check fails, nothing is lent, notPlanned logs "no planner on the crew", and the stall message explains. - The lent agent keeps its own budget, and the repository's ceiling and slots apply to it as to any crew member.

• Stall reason, admins only.

- The studio autonomy card shows #direction-stall only to admins. - The terminal's Vision screen shows it under "Direction". There is no src/tty.ts in this repo, so I put it in src/tui/screens/vision.ts. - MCP vision returns it as directionStall (null for non-admins). docs/MCP.md and the tool doc string are updated.

• README. A paragraph on the lent planner, covering the owner scoping and where the reason shows.

Tests (test/planner-lent.test.ts, plus one assertion in test/mcp-vision.test.ts)

• The page renders the stall, and it is absent once a planner is lent.
• The terminal Vision lines carry the stall.
• The second stall message appears when a planner exists but no direction issue does.
• Another owner's private repository is not lent atlas, and ensurePlanner returns undefined. driveRepo does not plan in that case, and the first stall message shows.
• The crew.added event is emitted once for the lent planner.
• An actor who is not an admin of the repository cannot lend, even when a candidate exists.
• MCP vision returns directionStall null for the owner when no stall applies. I did not add an MCP case where it is set, or one for a non-admin.

Priority The vision's order puts the pipeline first, and this is an autonomy fix, so it does not belong ahead of #6534, #6611 or #5276 on merit. It is a small fix for a silent failure the owner hit on a freshly migrated repository, and I'd leave the ordering to a person.