Plan documentation architecture beyond BBQ

[joanjcaceres]

Context

The current rendered documentation is intentionally BBQ-first. As SCCircuits
documents Circuit, fitting tools, point picking, iterative diagonalization,
and future graph/cQEDraw workflows, the site will need an information
architecture that does not force every user through the BBQ section.

Questions to answer

• What are the top-level researcher workflows that should become first-class
  docs sections?
• Which pages remain BBQ-specific, and which pages become shared theory or
  reference pages?
• How should tutorials, API references, validation examples, and media-rich
  walkthroughs be separated?
• What should be the entry path for users arriving from cQEDraw versus users
  arriving from Python/PyPI/GitHub?

Proposed direction

Keep the current BBQ trust pack as the first complete workflow. When at least
one additional workflow is ready, restructure the site around workflow-level
sections, for example:

• Start Here
• BBQ / Matrix Quantization
• Hamiltonian Modeling
• Fitting and Data Workflows
• cQEDraw Integration
• Theory and Validation
• API Reference

Acceptance criteria

• A proposed MkDocs navigation structure is written before large docs expansion
  begins.
• Existing BBQ pages keep stable URLs or have clear redirects/links where
  MkDocs supports them.
• Shared theory pages are not duplicated across workflow sections.
• README and repository sidebar still route users to the correct first-use
  path.
• pixi run -e sccircuits docs-build passes after any restructure.

Related work

• Issue Make SCCircuits documentation discoverable for researchers #70 established the rendered MkDocs site as the canonical public docs
  surface.
• Issues Document graph-to-matrix quantization and reduction pipeline #64 and Document graph-to-Lagrangian reduction layer before BBQ #66 cover graph-to-matrix and graph-to-Lagrangian
  documentation topics that may become part of the broader docs architecture.