Investigate tickets across the team's repos and ask a person only what they alone can answer - #473

Summary

Makes the planner investigate tickets about missing or wrong data the way a person would, for every team:

• It reads the team's other connected repositories when the code that produces the data isn't in the run's repository, and follows each consulted repository's own instructions.
• It traces the record layer by layer to the first wrong layer.
• It asks a person only what nobody but a person can answer, stating what it already checked.
• When it can't take the next step itself, it ends with that one step and what each outcome would mean.

Before this, a ticket filed against a web repository about records missing from the site was investigated only there. The search index builder lives in another repository, so the run never found it. It then asked a question based on a misread field (a date the pipeline copies from another date) and stopped.

Changes

Cross-repo investigation (passes/cross_repo.rs, plan.rs)

• Before: the planner could already pass repo to its tools, but nothing told it when to.
• Now: a search_code with no repo that finds nothing in the run's repository searches up to 8 of the team's other connected repositories, read-only. The hits come back labelled by repository.
• The planner's system prompt says the other repositories are part of the investigation and that the plan names which repository holds which layer.
• Other repositories are now read at their own default branch. Before, they were read at the run's base branch, which may not exist there.
• Writes are unchanged. fix_location already records a producer as owner/repo:path, counts files opened in other repositories, and plans other_repo steps.

Instructions from every consulted repository

• Before: the planner got AGENTS.md / CLAUDE.md and the team's Instructions only for the run's repository. The Jira repo picker already read the team's Instructions for every candidate repository.
• Now: the first read of any other repository in a run (a direct read or a fallback hit) adds that repository's instruction files and the team's Instructions for it to the tool result, once per repository.

Missing or wrong data method (fix_location::MISSING_DATA_GUIDANCE, bug and question tickets)

• Trace the record source, then store, then index or cache, then UI, and find the first wrong layer.
• Look records up by stable ids, not display names, and settle conflicting findings first.
• Read where a field is written before trusting its name.
• For incremental syncs, compare the record's change time to the sync cursor and read recent sync warnings before suspecting business rules.
• Check production directly, and use the team's own tools first.
• The decision block gains evidence.layers (layer, where it lives, what it shows, its state). Reports render it as "Layer by layer".

Asking a person: the question gate (stop_rules::screen::asking_rule, stop rule 5)

• A CLARIFICATION_NEEDED: question now carries checked:, changes: and, when it rests on a field, written_at:. People see the first two as "Already checked" and "What the answer changes".
• The question reader now gets the team's repositories and every tool the planner has. It also reports whether the run could answer the question itself, which field the question rests on, and whether the run's findings about one record disagree.
• A question is held back, with the reason sent to the planner, when:
  • it lists nothing checked;
  • it doesn't say what the answer changes;
  • the run could answer it itself;
  • it rests on a field whose writer the run didn't cite with a real path:line (in any team repository) or a lookup it made;
  • the run's findings about the same record still disagree.
• Questions in the plan's decision, which don't stop the run, are held only to the last three, because they can't carry checked: and changes:. CoderHelm's own notices (decision) are exempt.
• If every question is still held back by these rules after one send-back, the run stops on its findings (unknown, no code) instead of failing.

One next step from a person (FixDecision.next_step)

• A bug or question decision that ends unknown must name one action, why the run can't take it, and at least two outcomes, each with its meaning. A decision without them is sent back once.
• The report ends with "The one step I need from you" and an "If ...: ..." line for each outcome, replacing the generic "please confirm" line.

PLANNER_VERSION is bumped so cached plans from the old planner aren't reused.

Verification

• cargo fmt --all --check
• cargo clippy -p common -p worker -p gateway --all-targets -- -D warnings
• cargo test -p common -p worker -p gateway
• New tests:
  • a search that finds nothing in the run's repository searches the team's others, skipping its own and continuing past a failing one;
  • a consulted repository's instructions come once, with its files and the team's Instructions;
  • a citation in another team repository is read there, and one in an unconnected repository is not;
  • the method's guidance and the decision block's layers and next_step fields are in the planner's prompt;
  • each asking rule holds a question back, a plain decision line is held only to the rules it can meet, and the reader's prompt and schema carry the new fields;
  • questions held back twice by the asking rules stop the run on its findings, while other stop rules still fail it as before;
  • next_step gaps, and the report with its layers, step and outcomes;
  • checked, changes and written_at parse, render and round-trip, and old stored questions still read.