Set Datamate Skills

Replace the set of skills attached to one workspace.

The mirror of PUT /skills/{public_id}/datamates, and it exists because the two directions are not interchangeable. That one is scoped to a skill and replaces its entire workspace set, so adding one skill to one workspace through it means sending that skill's complete set — which the caller must first read, one request per skill, or silently detach it from every workspace the client did not know about. This one is scoped to the workspace: it only ever touches rows carrying this datamate_id, so it needs no knowledge of where else any of these skills is attached.

Locks, in the order the whole feature uses — Datamate, then CustomSkill by ascending id, then CustomSkillDatamate:

1. The workspace, for update and requiring ownership. Attaching changes what that workspace's agent does, so it is a write against it; a tenant-visible workspace says who may look, never who may reconfigure.
2. Every named skill, for update and requiring the caller created it. The other direction already refuses a non-creator, and the two have to agree or the same attachment would be allowed from one side and refused from the other.
3. The attachment rows, in set_skills_for_datamate.

Both misses report 404 rather than 403 — whether someone else's workspace or skill exists is not this endpoint's to disclose, matching app/api/bindings/api.py.