fix(provision): honour caller deadline in postgres/mongo/queue k8s Provision

[mastermanas805]

Problem

Redis's k8s backend was fixed for the pro-provision-hang bug in #52, but the postgres, mongo, and queue backends still derived their provisioning context from context.Background() — discarding the caller's gRPC deadline. When the api caller's deadline fired (or it cancelled the RPC), the provisioner kept blocking up to 5 min on a wedged PVC/CSI attach and the api handler hung. This is the same hang class that drove the recent e2e-prod flakiness — just for db / nosql / queue instead of cache. (Found by a sibling-gap sweep after the deploy-failure fix; sections B/C of that sweep came back clean.)

The Background() was a relic from when the api passed a 10s provision deadline; the api now grants provisionTimeout(tier) = 4m anon / 5m pro, comfortably above the 30-90s legitimate pod startup.

Fix (mirrors redis #52)

• All three: provCtx := context.WithTimeout(ctx, 5*time.Minute) — derive from the incoming ctx (min of caller deadline and the 5m ceiling backstop). Caller deadline/cancellation now propagates to every k8s call + waitPodReady poll; legitimate startup is unaffected, only hangs/early-cancels fast-fail.
• Bounded the rollback namespace-delete to a fresh 30s background ctx (redis parity) so cleanup still runs when the incoming ctx is already cancelled, without a wedged apiserver pinning the goroutine.
• No server change needed: waitPodReady already honours ctx.Err() each poll, and the shared server.mapError already maps context.DeadlineExceeded/Canceled → retryable gRPC codes (api soft-deletes + 503s).

Tests

TestProvision_HonoursCallerDeadline per backend: a 300ms caller ctx fast-fails (<30s, asserted) wrapping context.DeadlineExceeded, instead of blocking for the pod-ready ceiling. make gate green.

Completes the pro-provision-hang fix across all four pod-backed resource types (redis #52 + this).

🤖 Generated with Claude Code