Add example Kubernetes manifests (Deployment + Secret) for AMS fleet-mode as a small-cluster alternative to docker-compose

[JSONbored]

Context

DEPLOYMENT.md's own fleet-mode framing already describes running "many parallel miner attempts on a host or small cluster," but today only Docker-based artifacts exist for this (a Dockerfile, and a sibling docker-compose.miner.yml issue in this same batch) — there are no Kubernetes manifests anywhere in the repo for the miner package, and the repo-root terraform//k8s-adjacent config that does exist is ORB-specific.

Dependencies

None — independently shippable. It does not require the docker-compose.miner.yml sibling issue in this batch to land first; both are parallel, independent packaging artifacts built on the same existing Dockerfile image.

Requirements

1. Add k8s/miner-deployment.yaml defining a Kubernetes Deployment for the miner CLI-worker, built from the existing Dockerfile image.
2. Make replica count configurable (e.g. via a replicas field an operator edits, or a documented kubectl scale command).
3. Set resource requests/limits appropriate for a CLI-worker pod (not a persistent server) — document the reasoning for the chosen values.
4. Provide per-pod persistent storage for /data/miner via a volumeClaimTemplate (or equivalent), ensuring each replica gets isolated state — never a single shared PVC/volume across replicas, since the miner's SQLite-backed local stores are not designed for concurrent multi-pod access.
5. Add k8s/miner-secret.example.yaml as a Secret template for GITHUB_TOKEN (and placeholder keys for coding-agent credentials), consistent with the _FILE-indirection pattern from the sibling secrets-file issue in this batch if that has landed, or plain env references otherwise.
6. Document the deploy sequence (kubectl apply -f k8s/miner-secret.example.yaml after filling in real values, then kubectl apply -f k8s/miner-deployment.yaml) and how to scale replicas, in a new DEPLOYMENT.md section or a k8s/README.md.
7. Do not touch any autonomous-loop, governor, claim-ledger, or attempt control-flow — this is packaging/infra only.

Deliverables / Acceptance Criteria

• k8s/miner-deployment.yaml added with configurable replicas, sane resource requests/limits, and per-pod persistent volumes
• k8s/miner-secret.example.yaml added as a Secret template for GITHUB_TOKEN and provider credentials
• Manifests validate as well-formed Kubernetes YAML (e.g. via kubectl apply --dry-run=client or an equivalent schema check)
• Deploy-sequence documentation added (DEPLOYMENT.md section or k8s/README.md)
• No shared-volume-across-replicas configuration present
• No changes to governor/attempt/claim control-flow

Test Coverage Requirements

This PR must ship with full test coverage for every changed line and branch — the repo's Codecov patch gate requires 99%+ coverage and the house standard is to aim for 100%, including both sides of every conditional/nullish-coalescing branch introduced. Since these are static infra manifests (not src/** logic), Codecov's patch gate does not apply to the YAML itself, but this PR must still ship: (1) an automated validation check (e.g. a script or CI step running kubectl apply --dry-run=client -f k8s/ or a YAML-schema validator) covering both a well-formed manifest (passes) and a deliberately malformed one (fails), exercised as a real test rather than manual eyeballing, (2) an invariant test/assertion confirming the Deployment's storage strategy is per-pod (a volumeClaimTemplate, not one shared PVC referenced by every replica) — the specific safety property this issue introduces, and (3) not applicable as a bug-fix regression test since this is net-new packaging, not a fix.

Expected Outcome

An operator running a small Kubernetes cluster can deploy N isolated miner workers with kubectl apply instead of hand-rolling manifests or being limited to docker-compose/bare docker run.

Links & Resources

• DEPLOYMENT.md — fleet-mode framing this fulfills
• Dockerfile (existing, in packages/gittensory-miner/) — image the Deployment builds on
• Sibling docker-compose.miner.yml issue in this batch — the single-host alternative
• Sibling _FILE secrets-indirection issue in this batch — credential-mounting pattern this Secret template should stay consistent with
• Theme: Self-host packaging & docs

[linear-code]

JSO-3718