feat(analysis): add entrypoint-aware repository dead-code profiles

[styler-ai]

Summary

Extend the existing atlas_symbol_relations analysis surface with repository-wide, entrypoint-aware dead-code classification. The current include_dead_code control can identify graph candidates, but it cannot answer the operational question “which source is unreachable from every executable boundary?” without the caller separately reconstructing runtime, tool, test, and dynamic entry points.

This should extend the existing 40-tool composition rather than add a new top-level MCP tool.

Use Case

A TypeScript repository can have several valid execution surfaces:

• a browser entry point included by the main TypeScript program;
• operational download or maintenance scripts invoked from package scripts or CI;
• unit and integration tests;
• generated, plugin, or configuration-selected entry points.

A narrow unused-export analyzer may report an exported function as unused because its real caller is an operational script outside that analyzer's program. A graph-only zero-inbound result can also be misleading when a parser or dynamic boundary is incomplete.

An agent needs one bounded ProjectAtlas result that distinguishes:

runtime-reachable
tool-reachable
test-only
documentation-only
unreachable-high-confidence
inconclusive-dynamic-boundary

Current Limitation

The v0.4.0 MCP schema exposes include_dead_code on atlas_symbol_relations, but:

• dead-code inspection is an option inside anchored graph analysis rather than a repository-wide closed analysis mode;
• no entry-point profile or explicit root set describes browser/runtime, operational tool, test, generated, or dynamic boundaries;
• file/symbol indegree alone cannot distinguish executable reachability from parser or resolution gaps;
• callers must manually combine search, package/workflow inspection, graph coverage, and source entry points before deleting anything safely.

Proposed Contract

Support a closed analysis request on the existing tool, for example:

{
  "view": "analysis",
  "analysis_mode": "dead-code",
  "entrypoint_profile": "all-executable",
  "deadline_ms": 15000,
  "node_limit": 5000,
  "output_bytes": 50000
}

Useful profiles:

• runtime
• operational-tools
• tests
• all-executable

Also allow an explicit bounded entry-point selector set when automatic discovery is incomplete.

Each candidate row should include:

• file and exact symbol selector;
• classification and confidence;
• roots that reach it, or proof that none do within the declared profile;
• parser/relation coverage and unresolved or ambiguous boundaries;
• whether package scripts, workflow commands, tests, generated files, or configuration contributed a root;
• candidate-only language when coverage is partial;
• bounded continuation and cancellation/deadline state.

Acceptance Criteria

• Repository-wide dead-code analysis works without a mandatory file/symbol anchor.
• Runtime-only, operational-tool, test-only, and all-executable profiles are distinct and documented.
• A fixture with a function used only by an operational TypeScript script classifies it as tool-reachable, not dead.
• A fixture with a function used only by tests classifies it as test-only.
• An unreachable exported function with complete coverage is returned as a high-confidence candidate with exact selectors.
• Unresolved/dynamic boundaries lower confidence or return an inconclusive classification rather than a deletion verdict.
• Limits, continuation, cancellation, and deadlines remain enforced.
• CLI and MCP expose the same classification contract without adding another top-level MCP tool.

Non-Goals

• Automatically deleting source.
• Treating tests or documentation exports as production reachability.
• Claiming certainty across unresolved dynamic loading, reflection, code generation, or incomplete parser coverage.
• Replacing language-specific compiler/linter evidence; this analysis should compose with it.