Redesign analyze as a concise semantic report instead of exhaustive fact dump

[Teakowa]

Goal

Make wright analyze answer useful project-level questions for human users by default, instead of printing every symbol usage record and every rule CFG measurement.

Context

#209 / PR #211 correctly separated analyze from lint, but the first implementation still exposes internal semantic inventories too directly. On a real Workshop project, output currently resembles:

PASS analyze — 509 symbol(s), 303 rule measurement(s)
  globalVariable bastionPosition: reads 22, writes 46, calls 0, rules 47
  globalVariable titleColor: reads 23, writes 1, calls 0, rules 9
  ...

This is technically distinct from lint but has poor product value: a user is asked to read hundreds of low-level facts that are often easier to understand from the source itself.

The intended distinction should be:

• check: correctness diagnostics;
• lint: configurable rule/policy findings;
• analyze: aggregates, semantic interpretation, anomalies, and top hotspots;
• inspect: exhaustive semantic facts and targeted semantic queries.

Scope

Redesign the default analyze report around useful aggregation and prioritization.

Potential first-slice sections should be evidence-driven and may include:

• program overview (rules, variables, actions/values where reliably available);
• control-flow summary and unusual/high-complexity rules;
• state/coupling summary, including highly cross-cutting variables rather than every variable;
• performance/stability indicators and top hotspots where Wright already has sufficient semantic evidence;
• ranked or thresholded anomalies that help a developer decide what to inspect next.

The default human report should prefer summaries and top-N/high-signal items. Exhaustive symbol/rule facts should remain accessible through inspect, structured APIs/JSON, or an explicit verbose/all mode if justified.

Non-goals

• Do not move lint findings back into analyze merely to make the report shorter.
• Do not invent unsupported runtime guarantees or fake server-cost estimates.
• Do not dump every symbol/rule by default.
• Do not duplicate Workshop/source-language semantics owned by other repositories.
• Do not require a broad new analysis framework before improving the default report.

Acceptance criteria

• Default wright analyze <real-project> output is bounded and useful on large projects; it does not print all symbols and all rule measurements.
• The report includes meaningful aggregates and at least one prioritization mechanism (for example top hotspots, thresholded anomalies, or ranked coupling/complexity).
• Every reported interpretation distinguishes exact/static evidence from heuristics where relevant.
• Exhaustive facts remain available through an appropriate machine/inspection surface without being lost.
• analyze --format json has a deliberate structured contract suitable for agents/embedding; human presentation does not dictate the machine schema.
• Real-project fixtures/tests demonstrate usefulness on a project large enough that exhaustive output would be impractical.
• Help/docs clearly distinguish analyze from inspect.

Planning notes

Start from real user questions: “what is unusual, expensive, coupled, risky, or structurally important in this project?” Avoid treating existing semantic data structures as the desired UI. Keep the first report narrow enough that every displayed section has actionable meaning.