sec(postgres): bound DedicatedProvider Neon HTTP client with neonHTTPTimeout (#32)

Closes SEC-PROV finding (audit wave 2026-05-29): NewDedicatedProvider used
`&http.Client{}` with NO timeout for the Neon Management API path. A hung
Neon connection would wedge the provisioning gRPC handler (and any caller
— worker storage tick, regrader) indefinitely, piling up goroutines until
OOM.

NeonBackend already bounds its client at neonHTTPTimeout (30s); the
DedicatedProvider path was an oversight in the same family.

Fix: 1-line — set Timeout on the &http.Client literal. Reuses the existing
constant so any future tuning lands in one place.

Production LOC delta: 1 functional + 5 comment lines.

Co-authored-by: Manas Srivastava <[email protected]>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: mastermanas805

internal/backend/postgres/dedicated.go

@@ -34,12 +34,17 @@ type DedicatedProvider struct {
 // NewDedicatedProvider creates a DedicatedProvider.
 // adminDSN is used when neonAPIKey is empty (local/dev simulation).
 // neonAPIKey triggers the real Neon API path.
+// SEC (2026-05-29): the httpClient uses neonHTTPTimeout (defined in neon.go)
+// so a hung Neon Management API connection cannot wedge the provisioning
+// gRPC handler indefinitely. Without this bound a default `&http.Client{}`
+// has NO timeout — a single Neon outage would pile up goroutines until the
+// pod OOMs. Matches the timeout already on NeonBackend.client.
 func NewDedicatedProvider(adminDSN, neonAPIKey string) *DedicatedProvider {
 	return &DedicatedProvider{
 		adminDSN:    adminDSN,
 		neonAPIKey:  neonAPIKey,
 		neonBaseURL: neonAPIBase, // reuse the constant from neon.go
-		httpClient:  &http.Client{},
+		httpClient:  &http.Client{Timeout: neonHTTPTimeout},
 	}
 }