CoderAIProvider: validate status.providerID as a UUID before Coder calls, and prove a delete 404 comes from Coder #323

Summary

Two hardening gaps in the CoderAIProvider controller. Both came from the final assessment of #312 (the delete path). Neither is a known exploit today.

1. status.providerID is used in Coder URLs without a UUID check

DeleteAIProvider, and the GET and PATCH calls in sync and disable, put status.providerID straight into /api/v2/ai/providers/%s. That route also accepts a provider name, and the SDK's URL.Parse resolves .. segments. A forged value such as ../../users/<id> would therefore send a request with the operator's site-owner token to another Coder route.

Only the controller's own role can write coderaiproviders/status, so this needs cluster-admin-level access today. The fix is cheap: run uuid.Parse on ProviderID before every GET, PATCH or DELETE that uses it (coderaiprovider_delete.go, coderaiprovider_sync.go, coderaiprovider_disable.go), fail with an assertion failed: error or a clear status reason, and add a test.

Gate: fix this before the controller is activated (#315).

2. A 404 on DELETE-by-ID is not proven to come from Coder

ReadBodyAsError turns any non-2xx answer into a codersdk.Error, including an HTML 404 from a proxy or a wrong base URL. The delete path then releases the finalizer, and the provider stays in Coder. This leaks a provider. It never deletes the wrong one.

Fix: trust the 404 only when the body is a Coder JSON error, or confirm Coder with a users/me call first.

Refs #154

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: medium