feat: adopt externally-provided server key (survive namespace rebuild)

[mxhob1]

Extends the peer key-provenance pattern (#2 / 347f8a7) to the SERVER key — the one place it was missed. On a namespace rebuild the operator currently mints a NEW server key (wireguard_controller.go:852 unconditional GeneratePrivateKey), so every peer breaks (they hold the old server pubkey). Fix: when a Wireguard CR is annotated vpn.wireguard-operator.io/server-key-source: external, the reconciler waits (requeue) for external-secrets to create the wireguard Secret and adopts it, instead of minting; and it derives the pubkey if ESO seeded only the privateKey. Build+vet clean. Tests run in CI (envtest needs KUBEBUILDER_ASSETS). DRAFT — branch-only, rolls to prod in a maintenance window (image pin stays ba5f12d). 🤖 Generated with Claude Code

[mxhob1]

Superseded by #11, which merged 2026-06-08 as add6b47.

Same problem (operator mints a fresh server key on namespace rebuild, breaking every peer handshake), different mechanism: this PR gated adoption on an explicit vpn.wireguard-operator.io/server-key-source: external annotation, whereas #11 shipped the convention form — the reconciler reads <name>-server (ESO-owned, sourced from 1Password) whenever the operator's own <name> Secret is absent, mirroring the existing <name>-peer peer-adoption convention. No annotation to set, no requeue-wait, and read-only on the source Secret so there's no co-ownership fight with external-secrets.

The convention version is live in prod (operator pinned at 0ce1117). Closing as done-by-other-means.