docs: define product use cases and commercial roadmap

[VPRamon]

Summary

Create a versioned product wiki under docs/product/ that defines what spod offers beyond Siderust and turns the commercial/product discussion into an actionable roadmap.

The wiki covers:

• product vision and positioning;
• Siderust vs. spod ownership boundary;
• buyer/persona definitions;
• capability ownership and migration map;
• feature-parity policy for consolidation work;
• commercial packaging (spod Engine, spod Validate, future managed service);
• commercial readiness gates and roadmap;
• detailed operational use cases:
  • onboard-GNSS POD;
  • fleet/constellation POD;
  • independent orbit validation;
  • mission commissioning;
  • historical reprocessing;
  • rapid/final processing classes.

It also links the product wiki from the root README.

Product guardrail

The wiki establishes the rule:

Remove duplicated implementation, not product capability.

This is now tracked by #19 and issue #9 has been updated so consolidation work must preserve or explicitly classify product capabilities before deletion.

Roadmap issues created

• Define and enforce spod product capability parity #19 product capability parity
• Implement the first real onboard-GNSS POD workflow #20 real onboard-GNSS POD
• Add dataset resolution and external input acquisition #21 dataset resolution/acquisition
• Introduce versioned mission profiles #22 mission profiles
• Build operational POD QC and run health reporting #23 operational QC/run health
• Add independent orbit validation and comparison workflow #24 independent orbit validation
• Add reproducible historical reprocessing and processing baselines #25 historical reprocessing
• Introduce operational latency classes and run scheduling policy #26 latency/processing classes
• Add production observability for POD jobs #27 observability
• Define stable product and artifact API for POD jobs #28 stable product/artifact API
• Preserve full SGP4/SDP4 capability during Siderust consolidation #29 preserve full SGP4/SDP4 capability
• Add mission commissioning and GNSS receiver health workflow #30 mission commissioning
• Add fleet and constellation POD orchestration #31 fleet/constellation orchestration
• Restore human-readable QC report artifacts at the service layer #33 human-readable QC report recovery
• Reintroduce LISA as a reference use case, not a core spod feature #34 LISA reference/example use case

The SGP4 upstream gap is also tracked in Siderust:

• Bring astro::sgp4 to full Vallado/AFSPC SGP4/SDP4 parity Siderust/siderust#98

Notes

This PR changes documentation only. It does not preempt the implementation decisions in #9-#13; it provides the product criteria those refactors should preserve.

Capability audit follow-up

A repository-wide audit of closed and open consolidation work found:

• the scientific removals in Remove duplicated POD scientific modules in favor of Siderust #8 are largely valid because the corresponding POD primitives exist canonically in Siderust 0.12;
• the former service-owned HTML QC renderer was accidentally removed with scientific QC code and is now tracked for recovery in Restore human-readable QC report artifacts at the service layer #33;
• the former run-manifest JSON schema does not require restoration because an equivalent tested schema exists in Siderust;
• LISA should be retained, if useful, as a reference/example use case rather than a core Cargo feature (Reintroduce LISA as a reference use case, not a core spod feature #34);
• full Vallado SGP4/SDP4 remains protected by Preserve full SGP4/SDP4 capability during Siderust consolidation #29 / Siderust #98.

The capability map and parity policy in this PR have been updated accordingly.

Superseded

This PR is intentionally closed without merge. The product documentation and use-case material is being migrated to the repository's GitHub Wiki so it can evolve as living product documentation rather than source-tree documentation.