Python SDK: typed bridge client bindings — executors + jobs surface of /v1/bridge

[RHDZMOTA]

Repo: fahera-mx/alissa-python-sdk. Give the SDK typed client bindings for the Local Bridge queue-mode REST surface, so Python consumers (the new alissa-code-executor-daemon repo's utility services, orcloop) can read and operate the queue without hand-rolled HTTP. The wire contract is api/src/routes/bridge.ts + api/src/schemas/bridge.ts in fahera-mx/studio.alissa.app (design doc: docs/design/local-bridge-queue-mode.md §5); mirror the zod shapes, do not invent fields.

Scope of the surface (under /v1/bridge):

• Executors: register (POST /bridge/executors), list, heartbeat, stop.
• Jobs: feed (GET /bridge/jobs), detail (GET /bridge/jobs/:jobId), claim, start, progress, fulfill, fail.

Design pins:

• Bindings only — no daemon logic. No polling loops, no claim state machines, no tmux: the Node alissa CLI owns the executor daemon. This module is typed request/response plumbing for observers and tooling.
• Reuse the SDK's existing client/auth core (token handling, base URL, error envelope) — follow however the SDK's current API modules are structured; do not introduce a parallel HTTP stack.
• Typed error mapping for the §5.3 codes, STALE_CONSUMER and CONFLICT in particular — callers must be able to branch on code, not string-match messages.
• Response models as typed structures (dataclasses/pydantic — follow the SDK's existing convention) covering the job row projection (status, failureKind, attempt/maxAttempts, timing, spec.title — the feed omits spec.prompt/result bodies by server design; model what the wire actually returns).
• Unit tests against recorded/fixture responses for every endpoint incl. at least one error-code branch; no live network in tests (follow the repo's tests-unit.sh conventions).
• README/docstrings: one short usage example (list executors, tail a job's status).

Out of scope: any executor daemon behavior; Studio-side changes; new endpoints (if the wire lacks something, note it — the API lives in the studio repo).

Definition of Done

The SDK exposes typed bridge bindings for all eleven executor/job endpoints, built on the SDK's existing client/auth core, with typed §5.3 error mapping (STALE_CONSUMER/CONFLICT branchable by code), response models matching the actual wire projections, fixture-based unit tests for every endpoint plus error branches, and a usage example in the docs.

Acceptance criteria

• All executor (register/list/heartbeat/stop) and job (feed/detail/claim/start/progress/fulfill/fail) endpoints have typed bindings mirroring api/src/schemas/bridge.ts — no invented fields, no daemon logic.
• §5.3 error codes map to typed errors branchable by code, covered by at least one test per family incl. STALE_CONSUMER.
• Fixture-based unit tests cover every endpoint with no live network, passing under the repo's tests-unit.sh conventions.

Autonomous-Dev: fahera-mx/alissa-python-sdk
Autonomous-Scope: alissa/*, README.md
Alissa-Task: TASK-1115046778

[RHDZMOTA]

Dev-loop activity — the daemon's mechanical spawn/retry/deferral log; one line is appended each time it queues (or defers) a worker session for this item. Not an operator page — escalations are separate comments.

• 2026-08-13 01:13:58 UTC — develop-fahera-mx-alissa-python-sdk-i2-a1 — issue edge — spawned

[RHDZMOTA]

Dev loop stalled? — attempt 1 has been in flight 40 min and has opened no pull request, but its session develop-fahera-mx-alissa-python-sdk-i2-a1 is still present in the machine's session listing. The daemon never respawns an attempt it cannot prove is gone (a second session would land on the same branch in the same worktree and open a duplicate PR), so it keeps deferring the retry — is that session still making progress? Operator options: check it, and if it is wedged alissa tmux kill develop-fahera-mx-alissa-python-sdk-i2-a1 to let the retry proceed, or finish the work by hand. Unassigning the issue alone is not enough — the daemon's ledger keeps aging this attempt regardless.

[RHDZMOTA]

Dev loop stalled? — attempt 1 has been in flight 135 min; PR #3 is still open — is that session alive? The daemon keeps deferring the retry while the PR stays open. Operator options: check (and if dead, kill) the developer session and close the PR to let the retry proceed, or finish the work by hand. Unassigning the issue alone is not enough — the daemon's ledger keeps aging this attempt while the PR is open.