Accept Update Capability

Take the held-back update on one capability (TOS-6779).

TOS-3760 shipped the accept path for skills only (POST /api/skills/{id}/ accept-update); connections got held-back DETECTION in TOS-5024 but no release, so a holder whose consent baseline fell behind the current version saw "v3 is waiting on you" and no way to say yes. This is the generic route, dispatched through the registry like acquire/release so the endpoint stays type-agnostic (the module-import guard forbids naming a per-type module here).

A CONSENT-WIDENING write, so it carries the same contract the skill endpoint established: no request body, because the only thing a caller could put in one is the permission set being approved, and the server must recompute that from the object rather than take it from a client that might be stale. The type's executor recomputes the delta through the same held_back decision the runtime serves, so what the UI showed and what this grants cannot disagree.

404 when the caller holds nothing here; 409 when nothing is held back, so a double-click cannot silently re-consent to a version that has moved on underneath the dialog.