Daemon groups: org-scoped member sets (design §6 PR 2)

[zfy0701]

Tracking issue for the second half of
docs/designs/daemon-groups.md
(#994): org-scoped member sets — a self-hosted install forms a group out of its
own local daemons, points agents at the group, and gets the same lease-driven failover
the k8s pool has.

Not urgent. Sequenced after PR 1 (folding the pool into member_set) has merged and
run in the environment that has a pool, so the unified model is exercised by the pool
before an org set is layered on it.

What lands (design §6, PR 2)

• Sets and membership: org-set CRUD in organization settings; membership on the
  daemon detail (join / leave); the three write-time invariants from §2 are already in
  place from PR 1 — an org set accepts only that org's daemons, an agent may reference
  only the org-less set or a set of its own org.
• Placement: one more entry per set in the placement selector (the selector already
  lists targets, not machines).
• The door: duty/claim, duty/fetch, duty/release and the heartbeat admit any
  daemon that is in a set — SCOPE_DENIED becomes "in no set". Eligibility is the
  single rule PR 1 established (claimant ∈ agent's set); no per-kind branch.
• The daemon: auth/ok announces the daemon's set (alongside the lease horizon it
  already announces); the enforcement predicate becomes "this connection is in a set".
  A daemon in no set behaves exactly as today.
• Live membership changes (design §3): two-phase and generation-fenced, in the
  drain/move order — stop and confirm the old authority, then commit. Removal vacates
  after the daemon acks or after its self-fence horizon if unreachable; enrolling a
  machine that has directly placed agents is the existing agent move applied once per
  agent inside one fence, with the move's force-reassign contract when the source is
  unreachable (operator confirmation is the boundary; there is no lease to wait on).

Operator prerequisites for a local set (design §5)

Shared Postgres across the set's members; re-cloneable workspaces (scratch does not
follow); bots ride the bundle so nothing per-machine is needed.

Load-bearing tests (design §6)

An org-scoped member of set G in org X claims a set-placed agent of X in G; the same
member is refused an agent of another set, another org, the pool, or a pinned machine;
a pool member is refused any org-set agent; the write-time invariants reject the wrong
enrolments; the pool's "never claims a local-daemon agent" test still holds; and the
same rollout test the pool passed — stop one member of a local set, its agents re-grant
to another with no message sent.

Deliberately not in scope

A daemon in several sets; cross-org sets with an org id; negotiating membership on the
wire (design §7). Also not here: shortening the upgrade window a rollout leaves (a
separate observation under #955's known issues).

Tracked under #955.

[zfy0701]

Note for whenever a second warm pool exists (per-set or per-tier): K8sDriver.ensureSandbox reuses an existing SandboxClaim as-is and never compares its warmPoolRef to the configured pool, so an agent whose pool changes stays on the old one until its claim is deleted — and deleting a claim garbage-collects the workspace PVC. Today there is one pool per install and its name is release-derived, so this cannot happen; it becomes relevant the day a set gets its own pool. (Was #1007, closed as not worth standing on its own.)