🤖 CoderProvisioner: bind each key record's operator token to the control plane UID #417

Problem

A provisioner key record names its token source by the CoderControlPlane name only. If that control plane is deleted and created again under the same name, but with another status.url, a key delete for an old record sends the new control plane's operator token to the old URL. Whoever controls the old URL then receives a valid operator token.

• status.pendingKeys (PR 🤖 fix: revoke a CoderProvisioner key created at an intermediate control plane endpoint #413): revokeKey reads the control plane by controlPlaneRefName and sends its token to the record's coderURL.
• The applied key fields (status.controlPlaneRefName, status.controlPlaneURL) have the same binding.
• main before 🤖 fix: revoke a CoderProvisioner key created at an intermediate control plane endpoint #413 is broader: on drift it sends the current control plane's token to status.controlPlaneURL (recordedCoderAPIURL, internal/controller/coderprovisioner_controller.go:304 and :784 at ef86c32), also when the control plane reference changed to another control plane. 🤖 fix: revoke a CoderProvisioner key created at an intermediate control plane endpoint #413 narrows this to the control plane with the recorded name.

Raised by Codex on PR #413: #413 (comment)

Possible direction

Record the control plane UID with each key record and with the applied fields. Before a delete, compare it with the UID of the control plane read by name. On a mismatch, send nothing, keep the record, and report it in a condition, so that an admin deletes the key by hand. Status without a UID (from older operators) needs a defined rule, for example: send only to the control plane's current URL.

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