🤖 fix: honor aggregated API delete preconditions

[ThomasK33]

Problem

The custom aggregated CoderTemplate and CoderWorkspace DELETE handlers ignore metav1.DeleteOptions. A client-supplied UID precondition therefore does not protect against deleting a different incarnation of an object.

Evidence and limits

TemplateStorage.Delete and WorkspaceStorage.Delete discard the options parameter. The apiserver handler passes those options to storage; these custom handlers do not use the generic registry's precondition checks.

A scratch template-storage experiment supplied an intentionally wrong UID and observed deletion of the existing canonical template, with err=nil and deleted=true, on both baseline cfdd89749111d542e3fc7632ea1b8fa1fae1b49b and #106 candidate ef29d3a598e60e55330ece26c48d641f0c978309. This was a mock-backend test, not a live HTTP request. Workspace handling has the same ignored parameter; its mismatched-UID case still needs a dedicated regression test.

Acceptance criteria

1. Add failing tests for mismatched UID preconditions in both DELETE handlers. Assert no template deletion or workspace delete build occurs.
2. Enforce supported UID/resourceVersion preconditions against the fetched identity using Kubernetes-compatible errors. Define resourceVersion behavior explicitly; do not silently ignore an unsupported supplied precondition.
3. Preserve ordinary delete behavior, matching-precondition success, namespace isolation, and opaque cross-organization errors.
4. State the remaining backend race boundary honestly; do not claim an atomic conditional delete unless Coder provides it. Keep larger concurrency redesign separate.
5. Verify the HTTP path on an owned isolated KIND/Coder setup, including a failed precondition leaving the original object intact. Retain native exits, screenshot/video, SHA/image binding, cleanup, and normal repository checks.

Ownership and trigger

Owner: maintainer desk. Prioritized API-safety follow-up after #106's disposition and before quickstart support is restored. This behavior predates #106 and remains unfixed there. Keep this distinct from leaf-name casing and template-import readiness.

---

Generated with xum • Model: coder:openai/gpt-6-astra • Thinking: xhigh