Pipeliner Client

**Surface:** frontend-only

Second half of the frontend. Show who a ticket is assigned to, and let a CTO/admin assign it to one of the project's developers, using the developers endpoint and the `can_assign` flag.

Sits on top of the status-controls half so the two changes to `TaskDetailPane.tsx` land in a reviewable order.

Per spec decision 7, the assignee name renders for **internal viewers only** — a client seeing "assigned to X" learns the staff list and who works on which account.

## Acceptance criteria
- [ ] The ticket detail pane displays the current assignee (display name) or an explicit "Unassigned" state — **for internal users only**.
- [ ] An ordinary client's panel is byte-for-byte today's: no assign control, no assignee name (asserted by test).
- [ ] The "Assign to Developer" control renders only when the payload sets `can_assign`; a developer and an ordinary client never see it.
- [ ] Options come from `GET /projects/{id}/developers`; an empty list renders an explanatory empty state ("no developer configured for this project"), not an empty dropdown.
- [ ] An explicit "Unassigned" option is offered and works.
- [ ] A successful assignment updates the pane without a manual refresh (query invalidation), and the new assignee then sees Move Forward on that ticket.
- [ ] Server refusals render inline and readably: 403 (not permitted), 422 (developer has no `redmine_user_id`), and the mapped upstream rejection (Redmine refused the id) — each asserted by test, none surfacing as a blank failure or an unhandled promise.
- [ ] The control remains available on a Backlog ticket (assignment is not a status change) while the panel still shows no Move Forward there.
- [ ] New i18n keys in **both** `en.ts` and `fr.ts` (real French, identical ICU placeholders).
- [ ] Vitest covers CTO, admin, developer (control absent) and ordinary client (control and assignee both absent).
- [ ] `npx vitest run && npx tsc --noEmit && npx eslint . && npm run build` all green.