Pipeliner Client

## Implementation landed on `dev`

Branch `feat/1510-internal-roles` → merged to `dev` (c0aab8d). All gates green:
- **Backend:** 1074 passed, 2 skipped · `ruff check .` clean · `mypy src` clean (159 files)
- **Frontend:** 941 passed (147 files) · `tsc --noEmit` clean · `eslint .` clean · `npm run build` clean

### What shipped
1. `clients.internal_role` {cto, developer} + `clients.redmine_user_id`, migration `0020_internal_roles` (both nullable, no backfill, up/down round-tripped on an ephemeral pgvector).
2. `domain/tasks/progression.py` — the single, pure home of the rule: `next_status`, `may_set_status`, `may_assign`, `can_move_forward`, `selectable_statuses`.
3. Real Redmine assignment: `assigned_to_id`/`assigned_to_name` on `RedmineIssue`, an assignee write on the port + adapter with an `UNASSIGN` sentinel, and `get_user` for admin-time validation. `RedmineError` moved to the domain so a use case can catch "the upstream refused" without the application importing infrastructure.
4. Role-gated transitions on the REST route **and** the MCP tool, plus `POST .../assign` and `GET .../developers`.
5. `PATCH /admin/clients/{id}` with the Redmine id verified against Redmine before storing.
6. `StaffActionBar` + the admin `InternalRoleEditor`.

### The correction that came out of review
The rule is **target-aware**, and `allowed_statuses` is now narrowed **server-side** to what the viewer may actually set. A developer is handed exactly their one legal step, so "a developer cannot reach any other status from the UI" is a property of the payload — an option never sent cannot be forced open with devtools.

### The credit gate
Asserted per-role (CTO, platform admin, assigned developer, ordinary client) on the REST route **and** through MCP: a Backlog ticket raises `BacklogNotSubmitted` before any role is consulted. Backlog is refused as a *target* too, so a ticket cannot be pushed back and charged twice. Assignment is allowed on a backlog ticket and provably changes no status.

### On the MCP tightening
Checked prod before shipping it: the backend logs **6 `POST /mcp` requests in 30 days**, and the access log carries no tool name. That is effectively zero usage — the MCP server itself only shipped ~9 days ago — so no tenant is relying on `transition_ticket` and **no release note is warranted**.

### Out of scope, as decided
Teams (no team entity exists); an MCP `assign_ticket` tool; assignment notifications. Project membership for internal users was **not** rebuilt — it already exists (`POST/DELETE /admin/clients/{id}/projects`, `ClientProjectsDialog`).

## Code review — two blockers found and fixed

A full adversarial review of the branch diff. The **backend invariants all held** under it: the credit gate, the tenant boundary (`owned_project` untouched, still resolving before any role check), the target-aware developer rule, and `is_admin` ⟂ `internal_role`. The rule lives in one pure module, and the `RedmineError` move to the domain is complete.

The holes were on the frontend, and two were blocking:

**B1 — two id spaces confused.** The assign dropdown compared `detail.assigned_to_id` (a **Redmine user** id) against `dev.client_id` (a **dashboard client** id). Both are small integers starting near 1, so collisions were likely rather than exotic: a ticket held by Redmine user 3 would pre-select whichever developer happened to be client 3, while the facts rail underneath correctly named someone else — the pane contradicting itself about who owns the work, with no way for the CTO to correct it because the value already "matched". In the non-colliding case the real assignee always rendered as the disabled "departed developer" option, so the escape hatch became the normal path.
Fixed by carrying `redmine_user_id` on `DeveloperOut` and matching on it. Writing the regression test surfaced a **second instance of the same confusion** — the select's `value` was still the Redmine id while its options used client ids.

**B2 — a ticket could become permanently un-unassignable.** An empty developer list returned before the `<select>`, so the moment an admin cleared a developer's Redmine mapping or removed their project membership, their tickets were stranded on them with no UI route back. The API was fine; only the control was missing.

**S1 — the accessibility contract was dead code.** Move Forward sourced its label from `allowed_statuses`, which is viewer-narrowed and **empty** for a developer who is not the assignee — so the button vanished in precisely the state its tooltip exists to explain. Now labelled from a new `next_status_name`, shipped alongside `next_status_id` for exactly this reason.

**S3/S5** — removed the frontend's Backlog filter (a silent second copy of the credit gate) and the duplicated constants; a non-numeric Redmine id parsed to `NaN` and was sent as `null`, silently clearing the mapping while reporting success.

Also corrected: the spec named a `move-forward` route that was never built (the FE reuses `transition` with `next_status_id`, which is the better call — one write path, one rule application), and **§IR.9** now records where the implementation departed from the design rather than leaving the two disagreeing.

Gates after the fixes: backend **1075 passed** / ruff / mypy · frontend **943 passed** / tsc / eslint / build.

**Production smoke test — verified live against `pipeliner.omdev.tech`**

Deploy landed: containers restarted, database at `0020_internal_roles`.

- `GET /openapi.json` confirms every new surface is live — `PATCH /admin/clients/{id}`, `POST .../tasks/{id}/assign`, `GET .../developers`, the six new `TaskDetailOut` fields, and `internal_role` on `ClientOut`.
- All three new routes return **401** unauthenticated.
- **The viewer-narrowing works**: `get_ticket` on a Backlog ticket now returns `allowed_transitions: []` for an ordinary client. Before this deploy the same shape of call returned `[Backlog, Submitted]`.
- **The MCP tightening works**: `transition_ticket` as an ordinary client is refused with the actionable message — *"Changing a ticket's status is reserved for internal users. You can still submit a backlog ticket, reopen a shipped one, comment on it, pause it, or edit it while it is editable."* — and the ticket's status was left unchanged.
- **This very comment is the regression test** for the client's remaining verb set: posted through MCP `comment_on_ticket` as an ordinary client, after that refusal. Commenting, submitting, reopening, pausing and editing are all untouched.