The crew's planner plans through one route that refuses an issue with no pillar: `POST …/plan` in the JSON API #1063

Replaces #713, parked twice:

• the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #964 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.
• the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #1024 closed).

Those checks went red on tests this change does not touch. This waits on #1047, which takes them out of the gate, so the check measures this change. Start from today's main. What done looks like is #713's, unchanged:

---

Pillar: P0 Trust (umbrella #586). One run, started fresh from today's main, after #706 has landed.

Outcome (what a person sees). Nothing the crew's planner opens can reach the ready list without saying what it is for. The forge refuses it; the planner reads the refusal and either names the pillar or defers the issue with its one sentence.

Today. #706 makes the MCP plan tool refuse an item that names no pillar. The crew's planner does not use that tool: its brief has it open issues and links one at a time with curl (POST …/issues, POST …/issues/N/dependencies). For the planner the rule is a sentence in src/crew/brief.ts, not a refusal.

Acceptance.

• [ ] POST /api/v1/repos/:owner/:name/plan takes { issues } and calls the same action the MCP tool calls (openPlan, src/actions/plan.ts): the same items, the same refusals, all or nothing, rw scope. A crew member's run token may use it.
• [ ] The planner's brief tells it to plan through that route, with one worked example that carries a pillar item and a later item with why. The one-at-a-time instructions leave the planner's brief.
• [ ] A planning run through the stand-in agent (the fake Claude of test/crew.test.ts) that posts a plan with an item naming no pillar gets no_pillar, and nothing is opened. The same run with the pillar named opens the issues under the umbrella.
• [ ] Decide, and write down in docs/PLANNING.md, what an issue opened outside a plan is for in a repository with pillars (a builder splitting a task too big for one run). The simplest rule: a split child serves its parent's pillar.

Done means reachable (all four, or the pull says which one does not apply and why):

• Page: does not apply; the map already draws the result
• API: the route above (MCP unchanged)
• Test: the stand-in planning run, refused and then accepted
• Look: does not apply

Start from: src/actions/plan.ts, src/core/pillars.ts, src/http/api.ts, src/crew/brief.ts, test/crew.test.ts, test/plan-pillars.test.ts.

Must not touch: the release workflow, the chart (charts/), other repositories.