feat(common): add statefulset template alongside deployment

[eskp]

Summary

Adds opt-in StatefulSet mode to the common chart. Mirrors deployment.yaml 1:1 — only kind, serviceName, podManagementPolicy, terminationGracePeriodSeconds, and container lifecycle are new.

Use case	Mode
Stateless web/worker, multiple replicas, rolling deploys	deployment.enabled: true (existing — unchanged)
Stateful single-replica with persistent state, RWO PVC	statefulset.enabled: true (new)

First consumer is raita-bot (Discord daemon with EBS-backed Hermes profile). Multi-Attach errors during deploys + cleaner serial pod replacement semantics motivated the change.

What's new

• templates/statefulset.yaml — gated on statefulset.enabled. Surfaces `terminationGracePeriodSeconds` + container `lifecycle` hooks (preStop sleep, etc.) which the deployment template doesn't currently expose.
• templates/pvc.yaml + templates/storageclass.yaml — now iterate the union of `deployment.volumes` and `statefulset.volumes` so PVCs/StorageClasses are created regardless of which workload kind is enabled.
• values.yaml — new `statefulset:` section, fully documented inline.
• Chart bump 0.2.3 → 0.3.0 (minor: additive, backward compatible).

PVC name preservation = seamless migration

The PVC name pattern (<fullname>-<volume>-pvc) is identical between the two templates. A consumer can flip from Deployment to StatefulSet on the same Helm release without re-provisioning storage — the StatefulSet binds to the existing PVC.

For raita-bot specifically:

• Existing PVC: `raita-bot-prod-common-hermes-home-pvc`
• After flip: same PVC, same EBS volume, no data migration needed

Migration sequence (for the consumer)

1. `helm upgrade ... --set deployment.enabled=false --set statefulset.enabled=true ...`
2. Helm replaces the Deployment with a StatefulSet; PVC is unchanged.
3. New StatefulSet pod (`-0`) attaches to the same EBS volume.

Out of scope

• `volumeClaimTemplates` (per-replica volumes) — intentionally not in this iteration. The multi-replica + per-replica-PVC story needs more thought (PVC lifecycle on scale-down, naming, etc.). Today's StatefulSet mode supports the single-replica migration case, which is what raita-bot needs.
• Multi-replica StatefulSets are technically supported but will share the single PVC (so all replicas would mount-fail under RWO). For multi-replica, wait for the volumeClaimTemplates follow-up or use the existing Deployment mode.

Test plan

• `helm template` renders cleanly with `statefulset.enabled=true` and a raita-bot-like values set
• PVC name matches what existing Deployment-based releases already use
• Pre-existing chart lint error (`templates/tests/test-connection.yaml` referencing undefined `service.port`) is unchanged — not introduced here
• Reviewer: render with each existing service's values to confirm no behavioural change when `statefulset.enabled` is left at its default (false)

Companion PR

• raita-bot repo: KeeperHub/raita-bot#6 — flips raita-bot to StatefulSet once this lands and the chart is published.

[github-actions]

🎉 Helm Chart Tests Passed!

All modified charts have been successfully validated:

Chart	Version Check	Template Validation	Dry-run Installation	Overall Status
common	✅ Incremented	✅ Passed	✅ Passed	✅ Passed

Summary:

• ✅ Charts tested: common
• ✅ All template validations passed
• ✅ All dry-run installations passed

📋 Detailed Information:

• 🔗 View workflow run
• 📁 Download detailed test logs
• 💡 Click the download link above to get detailed logs for all helm operations.

The PR is ready for review! 🚀

Note: Charts will be automatically released when this PR is merged to main.