Set Custom Skill Workspaces

Replace the set of workspaces a skill is attached to.

The whole desired set arrives in one request, so associating a skill with several workspaces is atomic: every id is validated before anything is written, and a bad id leaves the previous set untouched.

Three locks in a fixed order, and the order is the contract:

1. The skill row. set_datamates_for_skill is read-modify-write — it reads the current set and applies a diff — so without this two requests naming disjoint sets never contend on any workspace row, both read the same current set, and both merge their own addition. Starting from {}, one asking for {1} and one for {2} commit {1, 2}: a set neither caller asked for, from an endpoint whose whole contract is "replace". The same lock is what stops a concurrent DELETE leaving attachments behind on a tombstoned skill.
2. The workspaces, ascending by id, in _lock_workspaces.
3. The attachment rows, in set_datamates_for_skill.

Workspaces before attachment rows is what keeps this from closing a cycle with soft_delete_datamate, which takes Datamate then CustomSkillDatamate and never wants CustomSkill.

The response describes the association and nothing else. It used to return the whole skill, which meant reading SKILL.md from S3 after the commit — so an S3 blip turned a write that had already landed into a 500, and the client would retry an operation that had already succeeded. Nothing here changes the bundle, so there is nothing to read.