fix: focus Code Context answers and accept generic repo checkouts

[alphali]

Summary

A checkout named repo could not connect because the privacy validator matched its name inside every generated repo_… reference. Validate these fields as mapped opaque identifiers while keeping repository-name checks on ordinary text.

Specific behavior requests now collect the answer and relevant execution conditions; whole-feature requests retain flow and sibling coverage. Check exact fixture values against their guards before claiming success, and do not modify helper validation to force a submission. Release plugin 0.2.7 across the existing Codex, Claude Code and Cursor manifests.

Compatibility

No endpoint, authentication, or payload-schema changes. The related server improvement is trd #475; either side can ship first. Full compatibility and rollout details are in the change set.

Verification

• npm test passed: complete connected helper lifecycle using a checkout named repo; prose containing local repository names and unmapped references are still rejected; idempotency and agent-origin finalize remain covered.
• Skill frontmatter and three-host release validation passed. CI verify passed.
• Two independent coding-agent runs inspected the same fixed public oRPC revision using the candidate plugin and the actual MCP service. The original narrow request submitted 4 base findings plus 2 invocation-origin findings; the whole-feature counterexample submitted 10 base findings plus 2 supplemental findings. Both submissions were accepted as ready_to_create.
• The narrow answer retains the correct in-process/no-extra-oRPC-HTTP explanation without broadening into React/optimistic feature coverage. Its illustrative return/fixture details are still more than the minimum answer. The broad request retains direct, hook, optimistic, success and error behavior.
• Both runs corrected local candidate-validation diagnostics without editing the helper. The wide checkout had no installed Vitest binary, so its source tests were read but did not execute.

The MCP runs use legacy packets from the current server, not a deployed candidate server. They stop at Code Context acceptance; downstream TRD generation and host installation are not claimed. This is a small regression check, not a representative benchmark score. No credentials or private benchmark state are included in this PR.

Both post-submission pulls independently confirmed ready_to_create with zero open questions. Tracked benchmark source and the candidate helper remained unchanged.