Separate analysis snapshots from diagnostics and rendering

[elazarg]

Problem

AnalysisResult stores important facts, but diagnostic behavior is coupled to result storage and rendering paths:
invariant printing, observation checking, first failure selection, unreachable analysis, and failure slicing.

Reusable tooling needs to query one analysis result in several ways without rerunning analysis or rebuilding display
state.

Direction

Introduce a queryable analysis snapshot that owns the analysis result plus the context needed to explain it.

AnalysisSnapshot {
  result
  variable_registry
  prepared_program_id or prepared program reference
  analysis_options
  dependency metadata
}

Then move diagnostic and rendering behavior into separate components:

DiagnosticsEngine
  find_first_error
  compute_failure_slices
  find_unreachable
  check_observation
  explain_assertion_failure

Renderer
  print_invariants
  print_failure_slices
  print_cfg
  render_json

PR-sized closures

• Add AnalysisSnapshot as a wrapper over current AnalysisResult plus VariableRegistry.
• Move one diagnostic query at a time to standalone functions operating on the snapshot.
• Keep existing public/CLI behavior as wrappers while internals migrate.
• Separate rendering options from analysis options where they are currently conflated.
• Add structured output for diagnostics only after the snapshot/query boundary is clear.

Related existing issues

• #1010 is the main existing diagnostic-reporting issue. It already
  contains a substantial proposal for verbosity modes, slices, reachable-block output, JSON/SARIF, and
  interactive/server
  queries. If opening this draft, either make it a parent architecture issue for Invariant output stops at first error, hiding loop predecessor state needed for debugging #1010 or fold this content into Invariant output stops at first error, hiding loop predecessor state needed for debugging #1010
  rather than creating an unconnected duplicate.
• #688 asks to interleave source lines with verifier output. That belongs
  in rendering over a diagnostic snapshot.
• #995 is closed but related to minimal failure slices.
• #680 is closed but relevant API history: callers want queryable register
  type/range information, and a snapshot/query boundary is the right place to expose that.
• #632 and #463 are closed
  historical debugging-output issues.

Related PRs

• #1061 extracts compute_slice_from_label from
  compute_failure_slices, making slicing available for arbitrary labels. If it lands, this issue should treat that as
  existing infrastructure rather than re-requesting it.
• #1062 adds AnalysisEngine sessions with live access to
  AnalysisResult; this may be the first concrete home for snapshot-like query operations.
• #1047 exposes invariants, errors, CFG, disassembly, source mapping,
  slicing, and constraint checks through MCP. The diagnostic snapshot issue should define the protocol-independent
  library boundary underneath that PR, not duplicate the MCP tool layer.

Notes

This is a prerequisite for good server behavior, but it is useful before any server exists. It improves tests because
diagnostic queries can be exercised directly over a stable analysis snapshot.