docs: design for decoupling snapshot generation from publishing

[bdchatham]

Summary

• Design doc proposing a nested TendermintSnapshotGenerationConfig under SnapshotGenerationConfig so we can grow sibling modes (seidb, app-layer, …) without renaming fields.
• Adds an optional publish: {} sub-struct whose presence enables S3 upload — absence means "generate + retain locally only." Closes the gap where a full-node can't produce N on-disk snapshots without also pushing to S3.
• Rejects enablePersistence / enabled: bool in favor of present/absent struct to match existing CRD precedent (StateSyncSource struct{} at api/v1alpha1/common_types.go:107, and the snapshot: { stateSync: {} | s3: {...} } shape already used for bootstrap sources).
• No launched product → no migration / backward-compat work; sample manifests and tests are updated alongside the type change in the implementation PR.

Key shape

spec:
  fullNode:
    snapshotGeneration:
      tendermint:
        keepRecent: 5
        publish: {}          # omit to keep snapshots local-only

Open questions deferred to LLD

1. Sidecar signal mechanism — explicit flag in rendered config vs. keying on bucket-var absence.
2. Where cross-field validation (publish set ⇒ keepRecent >= 2) lives — Condition on reconcile vs. OpenAPI oneOf vs. new webhook.
3. Operational note for any already-running dev archives that previously uploaded and would stop once publish is omitted.

Test plan

• Review the shape and naming (publish: {} vs. enabled: bool) — biggest design decision in the doc
• Confirm the outer wrapper (SnapshotGenerationConfig { Tendermint: ... }) is worth the nesting level vs. collapsing to tendermintSnapshotGeneration: directly on the spec
• Validate the assumption that the sidecar is the component doing the S3 upload (§2 of the design)
• Decide which of the three open questions need LLD-level answers before implementation vs. can be decided in the implementation PR

🤖 Generated with Claude Code