Resolve the Longhorn replica-tier contradiction for databases

[kelchm]

Summary

docs/architecture.md prescribes 3-replica Longhorn for critical PVCs — explicitly databases — but the only StorageClass ships defaultClassReplicaCount: 2 (kubernetes/apps/longhorn-system/longhorn/app/helmrelease.yaml:49), and all three CNPG clusters select storageClass: longhorn (kubernetes/apps/ai/metamcp/app/cluster.yaml:14, kubernetes/apps/iot/visionect/app/cluster.yaml:17, kubernetes/apps/printing/bambuddy/app/cluster.yaml:13). Every database runs 2 replicas while the authoritative doc claims 3. Given single-instance CNPG clusters with no WAL archiving (#224), the replica count is a real durability input, not cosmetic.

Proposed work

• Decide the intended tier: if the documented policy stands, create a longhorn-3replica (or similar) StorageClass and adopt it for the CNPG clusters; if 2 replicas is the accepted trade-off, correct docs/architecture.md and record the rationale.
• Verify live numberOfReplicas on existing volumes after any change (existing PVCs keep their provisioned replica count).

Acceptance criteria

• Docs and deployed replica policy agree, with the decision recorded.
• Database PVCs run at the decided replica count, verified live.

Related

• Correct and drill full-cluster disaster recovery #224 (CNPG backup/durability gap)
• Establish an independent immutable off-site backup path #297