Expose semantic queries through the Wright inspect workflow

[e54-bot]

Goal

Expose Wright's existing project-semantic query capabilities through the CLI without expanding the top-level command inventory for each query primitive.

Humans and agents should reach the same underlying semantic services through one coherent inspect workflow.

Context

Wright already exposes semantic queries such as symbols, references, usage, CFG, call graph, cost estimates, and persistent-object facts through wright-agent/v1, while the CLI currently exposes only the broader wright inspect summary.

The agent contract also addresses some query targets through session-local numeric ids. Those ids are awkward for direct CLI use and create two numbering spaces for related concepts. Name-based addressing is the appropriate shared user-facing contract where names are unambiguous.

Top-level CLI commands should represent distinct user intents rather than every semantic primitive. Detailed semantic queries are variants of the existing inspection workflow and therefore belong under wright inspect.

Scope

Extend wright inspect with focused query subcommands:

CLI surface	Existing agent operation
wright inspect symbols [INPUT]	symbols
wright inspect refs <NAME> [INPUT]	references + usage
wright inspect cfg <RULE> [INPUT]	cfg
wright inspect callgraph [INPUT]	callGraph
wright inspect cost [INPUT]	costEstimate

• Keep plain wright inspect [INPUT] as the overview entry point.
• refs absorbs usage counts rather than creating a separate usage CLI command.
• Fold persistent Workshop object facts into the existing analyze report rather than creating another inspection subcommand unless a distinct user workflow later requires one.
• Add name addressing to the shared driver/analyzer model and to references, usage, and cfg on wright-agent/v1; retain existing numeric addressing for compatibility.
• Unmatched or ambiguous names must return structured diagnostics rather than guessing or silently succeeding.
• Every inspection subcommand accepts the relevant existing common options and emits the normal wright-result/v1 envelope under --format json.
• CLI and agent surfaces must use the same underlying query/result model rather than implementing independent query logic.
• The overview output/help should make the detailed inspect subcommands discoverable.

Non-goals

• Adding symbols, refs, cfg, callgraph, or cost as top-level commands.
• Adding a separate generic query top-level namespace.
• targetMetadata; it is project-independent catalog data and should be handled through the appropriate catalog/product surface separately.
• Removing or changing existing numeric addressing on wright-agent/v1.
• Adding session reload/incremental-state machinery solely for these queries.
• Adding new semantic analysis; this issue exposes capabilities Wright already computes.
• Redesigning unrelated top-level workflow commands.

Acceptance criteria

• wright inspect symbols, refs, cfg, callgraph, and cost run against a file or project directory and preserve the normal current-directory default.
• Plain wright inspect remains the overview workflow.
• Each inspection subcommand returns the same underlying result model as the corresponding agent operation; JSON-mode tests compare the two paths on representative fixtures.
• wright inspect refs <NAME> resolves a symbol by name and includes the usage counts currently exposed separately by the agent usage operation.
• wright inspect cfg <RULE> resolves a rule by name rather than requiring a numeric rule index.
• references, usage, and cfg accept name addressing on wright-agent/v1; existing numeric requests continue to produce their current results.
• Unmatched and ambiguous names each return a stable structured diagnostic and non-zero exit/result status.
• wright analyze exposes persistent Workshop object facts while the existing agent operation continues to return the same data.
• wright inspect --help and the overview output make the detailed inspection surfaces discoverable without adding top-level commands.
• CLI/driver/agent contract documentation describes the nested inspection surface and name addressing.
• Ablation: removing shared name resolution from the driver/analyzer causes both CLI/agent equivalence tests or name-addressing tests to fail.

Dependencies / ownership

• Owner: Wright (wright-cli, wright-driver, wright-analyzer, agent contract, docs).
• No source-language owner change is required; these queries consume the canonical semantic program already available to Wright.
• Related: Roadmap to v1.0: stable Workshop tooling platform #134, Advertise only backed wright-lsp capabilities and declare the LSP support scope #421, Establish a product-level coding-agent benchmark for Workshop workflows #414, Add a first-party agent guide installer #415.

[e54-bot]

Dependency found while scoping wave 3: every reference span that Wright currently reports points at the wrong token. On overpy-cake.ws, all 17 references to cakePos cover Add or Set Global Variable instead of the identifier, and globals have no declaration span. See #433, which is blocked on wrightkit/workshop-rs#324. #429 can proceed. Until #433 lands, wright refs should present locations as coming from the existing reference model, not as exact identifier positions, and #429's tests should not assert that the sliced text of a reported span equals the identifier.