Pool-backed engine roles (#7 phase 2, DT side)

[andre-merzky]

The DT half of #7 phase 2. Companion PRs: radical-cybertools/radical.orbit#117 (dispatcher speaks the rhapsody execution dialect, batched persists/notifications) and radical-cybertools/rhapsody#88 (OrbitExecutionBackend pool mode).

Config: a role may name a dispatcher-managed pool instead of an endpoint, with the pool configs declared once at session level:

ENGINES = {
  "pools":   [{"name": "exsitu", "endpoint_name": "hpc1", ...}],   # dispatcher PoolConfig schema
  "engines": {"inference": {"endpoint_name": "dt_inference_ep"},
              "learning":  {"pool": "exsitu"}},
}

Semantics:

• one dispatcher session per DT session, keyed by the DT sid and shared by every pool-backed role; pools are declared with it (idempotent re-declare, so role build order does not matter)
• pool-backed roles opt out of the R8 endpoint-loss fail-fast: pilot loss requeues tasks inside the dispatcher; the twin's failure surface is a task that ultimately fails
• contract: requeued tasks re-execute — twin tasks stay idempotent (documented at the seam and in register_session)
• a pool config against a rhapsody without pool support fails the engine build with a clear error; without a pool, nothing changes — CI stays green on the current pins

Tests: pool kwargs land on the backend (dispatcher plugin, shared sid, declared pools, pool:<name> endpoint record), the old-rhapsody guard, and R8 sparing pool-backed roles. 171 unit + 29 integration pass.

Merge order: after the two companion PRs land, the CI/install pins move to versions carrying them; until then the pool path is config-gated and inert.

🤖 Generated with Claude Code

https://claude.ai/code/session_016Npyz3Hbnwos12ESsdJ2YU