Description
Defense #5 in the mesh.yaml hardening track. Today the [hydraguard runbook](https://github.com/cederikdotcom/hydraguard/blob/main/docs/runbooks/runbook.md) warns operators to keep the API service stopped:
> **API warning**: Keep the HydraGuard API service stopped (`systemctl stop hydraguard`) when not actively enrolling new peers. The `auto_apply: true` setting causes `/api/v1/air/provision` to regenerate peer keypairs on every call, breaking existing connections. See issue #64.
Thats a band-aid for a known broken code path, not a fix. As of 2026-05-11 the daemon on the Brussels hub IS running with `Auto-apply: enabled` per the journal logs — the runbook posture is not actually being followed in production.
## Suggested fix
In `pkg/api/handlers.go` (and wherever `/api/v1/air/provision` is implemented): make the provision call **idempotent**. If a peer with the requested ID already exists and has a public key, return the existing config rather than rotating keys. Key regeneration should be an explicit operation (`/api/v1/air/{id}/rotate-keys`), never a side effect of provision.
Also set `auto_apply: false` as the default in `api.yaml` so a fresh install does not arm the footgun.
## Verification
- Call `/api/v1/air/provision` twice for the same peer ID. Second call returns the same config the first did (same public key, same address) — no regeneration, no disruption.
- Default `api.yaml` template generated by `hydraguard hub init` has `auto_apply: false`.
- Update the runbook to remove the keep-API-stopped warning.