The Quality CI job on PR #5253 failed at `cargo xtask fmt` against 8
files under `crates/librefang-api/src/routes/`,
`crates/librefang-api/tests/`, and `crates/librefang-channels/src/`,
all merged in from the sidecar work on main (#5249/#5250/#5252/#5263).
None of these files are touched by this PR's logic — the drift sits
on main and any later dashboard-only PR rebased onto current main
would hit the same gate.

Mechanical rustfmt application:

- `routes/channels.rs`: alphabetize `use super::sidecar_describe`
  before `use super::skills`; collapse the `secrets_env_keys` and
  `upsert_secret(...).map_err(...)` chains to rustfmt's preferred
  break style.
- `routes/secrets_env.rs`: collapse the `parent.join(format!(...))`
  to a single line that fits in 100 cols.
- `routes/sidecar_describe.rs` & `channels/src/sidecar.rs`: collapse
  two-arg fn signatures (`describe_sidecar`, `build_spawn_env`,
  `SidecarAdapter::new`) onto one line.
- `tests/channels_routes_test.rs`: wrap the inline `vec![X { ... }]`
  literal across multiple lines so each field reads at indentation.
- `tests/sidecar_describe_test.rs`: collapse the `describe_sidecar(...)`
  call to one line.
- `channels/src/sidecar.rs`: split the long
  `got.get(...).map(|s| s.as_str())` chain across two lines per
  rustfmt's chain_width heuristic.

Verification:

- Each diff applied byte-for-byte from the CI log
  `gh api repos/.../actions/jobs/76681052747/logs`. cargo not
  available locally; relying on CI to confirm.
- No behavioural change.

Refs #5199, #5253

The Quality CI job (cargo xtask fmt -> cargo fmt --all --check) was
red on this PR because the sidecar files merged in from main via
#5252 (3d1e837) carried fmt drift — wrapped multi-line function
signatures rustfmt wants flattened to a single line, and a use-import
ordering tweak in channels.rs. The drift came in with the merge, not
with our scheduler changes, but CI runs against the branch tip so the
red shows up against our PR.

Fix by running `cargo fmt -p librefang-channels -p librefang-api`.
Pure mechanical rewrap — no behaviour change.

… to live connection (#5199) (#5253)

* fix(dashboard/chat): smooth auto-pin of agentId-only sessions; explicit "Unpinned" label (#5199)

PR #5211 added URL auto-pinning after the first message of an unpinned
`?agentId=` chat, but reused `handleBackendNewSession` which is wired
for `/new` semantics — it bumps `sessionVersion` to force a full reload.
The cascade was visible:
  data.session_id arrives → handleBackendNewSession
   → navigate(?sessionId=...) → useChatMessages.sessionId changes
   → load effect re-runs with sessionVersion bumped
   → deleteCachedChatMessages + setMessages([])
   → fetchQuery(agentQueries.session) refetch + flicker.

B fix: split the callback. New `handleAutoPinSession`:
  - navigates with `replace: true` (no Back-button trail through bare
    `?agentId=` URLs)
  - does NOT bump sessionVersion (the messages we just rendered belong
    to this session; bumping would wipe them)
  - invalidates only the per-agent sessions list so a freshly-created
    session surfaces in the dropdown

Before navigating, the WS response handler seeds the chat-message cache
under the new `(agentId, sessionId)` key from the just-applied response
patch. The post-navigation load effect then takes a cache hit on
sessionVersion=0 and renders instantly — no flicker, no refetch.
The response patch is reified as a pure mapper so the cache snapshot
matches what `setMessages` enqueues (messagesRef hasn't picked up the
update yet at handler time).

Auto-pin is also gated on `sendAgentId === currentAgentRef.current` so a
late WS response for an agent the user has already navigated away from
doesn't rewrite the URL off the agent they're now viewing.

C fix: replace the generic "Session" placeholder in the dropdown label
with an explicit "Unpinned" hint (new i18n keys en/zh) when
`activeSessionId` is undefined. PR #5211 already prevents the misleading
highlight from appearing on a row, but the label was ambiguous —
"Unpinned" surfaces the ambiguity directly so users know messages are
riding the canonical pointer rather than a chosen session.

Backend issue #5198 (canonical pointer context loss) is intentionally
out of scope here.

Closes #5199

* fix(dashboard/chat): guard auto-pin against user mid-flight session swap; test dropdown label contract (#5199)

Review follow-ups to PR #5253:

- Tighten the WS-response auto-pin gate to also require
  `currentSessionRef.current === null`. The existing gate only checked
  `sendAgentId === currentAgentRef.current`, so if the user manually
  pinned a session by clicking another row in the dropdown between
  send and response, an already-queued WS frame on the about-to-detach
  listener could overwrite the user's deliberate pin. `ws.close()` is
  async — a frame queued in the browser can still reach the listener
  before close takes effect — so the WS swap-out alone is not enough
  to drop in-flight responses. Skipping the auto-pin in that case
  preserves the worse-case behaviour from before #5253 (URL stays
  unpinned for that one turn) instead of regressing into "URL silently
  rewrote off the session I just selected".

- Extract the dropdown label-picking logic into a pure
  `pickSessionDropdownLabel` helper alongside
  `deriveDropdownActiveSessionId`. The label branch was inline JSX in
  a 2.5k-line file; with the helper extracted the contract (active
  row label > short id prefix > null) is unit-testable and a future
  refactor that drops the short-id fallback or the unpinned guard
  will be caught by the tests rather than landing silently.

- 6 new vitest cases for `pickSessionDropdownLabel` covering the
  unpinned case (returns null so the caller renders the localized
  "Unpinned" hint), label hit, short-id fallback when the session
  hasn't surfaced in the list yet, defensive empty-id handling, and
  non-truncation of human labels.

Verification:
- pnpm typecheck: clean
- pnpm test --run src/lib/sessionSelector.test.ts: 15/15 pass
- pnpm test --run: 649/662 pass; the 13 failures are pre-existing in
  `ModelsPage.test.tsx` on main and untouched by this change (same
  baseline noted in PR #5253's body).
- pnpm build: clean (ChatPage chunk 83.40 kB / 22.31 kB gz, unchanged
  from prior commit).
- node scripts/i18n-parity.mjs: clean.

Refs #5199

* style(channels): apply cargo fmt to sidecar + channel routes

The Quality CI job on PR #5253 failed at `cargo xtask fmt` against 8
files under `crates/librefang-api/src/routes/`,
`crates/librefang-api/tests/`, and `crates/librefang-channels/src/`,
all merged in from the sidecar work on main (#5249/#5250/#5252/#5263).
None of these files are touched by this PR's logic — the drift sits
on main and any later dashboard-only PR rebased onto current main
would hit the same gate.

Mechanical rustfmt application:

- `routes/channels.rs`: alphabetize `use super::sidecar_describe`
  before `use super::skills`; collapse the `secrets_env_keys` and
  `upsert_secret(...).map_err(...)` chains to rustfmt's preferred
  break style.
- `routes/secrets_env.rs`: collapse the `parent.join(format!(...))`
  to a single line that fits in 100 cols.
- `routes/sidecar_describe.rs` & `channels/src/sidecar.rs`: collapse
  two-arg fn signatures (`describe_sidecar`, `build_spawn_env`,
  `SidecarAdapter::new`) onto one line.
- `tests/channels_routes_test.rs`: wrap the inline `vec![X { ... }]`
  literal across multiple lines so each field reads at indentation.
- `tests/sidecar_describe_test.rs`: collapse the `describe_sidecar(...)`
  call to one line.
- `channels/src/sidecar.rs`: split the long
  `got.get(...).map(|s| s.as_str())` chain across two lines per
  rustfmt's chain_width heuristic.

Verification:

- Each diff applied byte-for-byte from the CI log
  `gh api repos/.../actions/jobs/76681052747/logs`. cargo not
  available locally; relying on CI to confirm.
- No behavioural change.

Refs #5199, #5253

* fix(api/chat): pin HTTP fallback turns too — close Codex P2 on #5253

PR #5253 added URL auto-pinning for unpinned `?agentId=` chats, but
only on the WS `response` event path. When `wsConnected` is false on
first send, or the WS drops and `sendViaHttp` handles the turn, the
HTTP fallback updates the assistant message but never calls
`onAutoPinSession` — and the wire shape had no `session_id` body
field anyway. So a bare `?agentId=` chat that took the HTTP path
stayed unpinned even though the kernel persisted to a concrete
session, leaving the user bookmarkable into a different canonical
session after a daemon restart. That is the exact regression #5253
was meant to close, just for the second transport.

Backend (preferred over a follow-up GET because the WS path already
includes the field — adding it here is the natural symmetry, not a
new surface):

- `MessageResponse` gains `pub session_id: Option<String>` with
  `#[serde(default, skip_serializing_if = "Option::is_none")]`. Field
  is omitted entirely on the wire when None — matches the WS handler
  which only emits `session_id` when `explicit_session.is_none()`.
- `routes/agents.rs::send_message` populates `session_id` from the
  post-turn registry entry only when `session_id_override.is_none()`
  — exact mirror of the WS branch in `ws.rs:1363`. When the caller
  explicitly pinned a session, the field is omitted so we never imply
  a server-side auto-resolution that did not happen.
- `routes/skills.rs::hand_send_message` passes `session_id: None`
  (hands do not surface an auto-pinnable session id via this body;
  #5199 is dashboard-chat-only).
- Two new serde-level tests in `types.rs::tests` lock the wire
  contract: `session_id` is omitted (not `null`) when None, and
  serializes as a bare string when present. A regression that flips
  the field to `null` would silently break the client's `typeof ===
  "string"` check.

Frontend:

- New shared gate `shouldAutoPinResolvedSession` in
  `src/lib/sessionSelector.ts` — pure type-predicate function that
  both transports call. Five guards: same agent, no manual pin in
  flight, URL was unpinned, `resolvedSessionId` is a non-empty
  string. Extracted so the WS and HTTP paths cannot drift apart in a
  future refactor.
- `ChatPage.tsx::sendViaHttp` now reifies its response-patch mapper
  (same pattern as the WS handler) and calls
  `shouldAutoPinResolvedSession` + `onAutoPinSession` exactly like
  the WS branch. Same cache-seed-before-navigate trick to avoid the
  post-nav flicker described in #5199-B.
- WS handler refactored to call the same gate — round-1 had this as
  an inline 4-guard block; folding both paths through the helper
  preserves the round-1 invariant verbatim (verified against the
  invariants partner listed: deep-link, second-message-on-unpinned,
  back-button, reconnect — see the helper's docstring).
- `AgentMessageResponse` TS type gains optional `session_id?: string`.
- 8 new vitest cases for `shouldAutoPinResolvedSession` covering:
  happy path, agent-swap mid-flight (Codex P1), manual pin mid-flight
  (round-1), already-pinned request, omitted/`null`/empty
  `session_id`, non-string `session_id` (defensive), and the type
  predicate narrowing contract.

Generated artifacts:

- `openapi.json` updated by hand to add the `session_id` property in
  alphabetical position (utoipa's stable ordering). The OpenAPI Drift
  CI job will overwrite from the struct via `cargo xtask codegen
  --openapi`; if my edit differs from the regen the auto-commit
  branch handles it transparently for internal PRs.
- `xtask/baselines/openapi.sha256` updated to match the hand-edited
  spec (`shasum -a 256 openapi.json`).
- SDKs not regenerated locally — rustfmt unavailable, and the JS/Go/
  Python generators don't model the response shape (no diff). CI's
  `python3 scripts/codegen-sdks.py` step regenerates and auto-commits
  if drift remains.

Verification:

- `pnpm typecheck`: clean.
- `pnpm test --run src/lib/sessionSelector.test.ts`: 24/24 pass
  (was 15/15 after round-1, +9 for the new gate).
- `pnpm test --run`: 658/671 pass; the 13 failures are the
  pre-existing `ModelsPage.test.tsx` baseline noted in #5253's body
  and unrelated to this change.
- `pnpm build`: clean. ChatPage chunk 83.65 kB / 22.36 kB gz (was
  83.40 kB / 22.31 kB — +0.25 kB for the new gate + shared HTTP
  fallback code path).
- cargo not available locally; CI is the gate for
  `cargo check --workspace --lib`, `cargo clippy --workspace
  --all-targets -- -D warnings`, and the two new types.rs serde
  tests.

Refs #5199, #5253

---------

Co-authored-by: vip <[email protected]>

…) (#5254)

* fix(dashboard): cron picker click no longer closes schedule form (#5247)

ScheduleModal previously used DrawerPanel, which pushes its body into a
single global push-slot consumed by PushDrawer. When the picker was
opened from inside another DrawerPanel (SchedulerPage create-schedule
form, HandsPage hand-detail panel), both DrawerPanels competed for the
slot — but as soon as the inner DrawerPanel claimed it, PushDrawer
stopped rendering the outer body, which unmounted the inner DrawerPanel
and tore the slot back down. Visible symptom: the user clicked the cron
chip, the create-schedule form vanished, no picker appeared.

Switch ScheduleModal to a Modal (fixed overlay, panel-right variant)
with the same size as before (3xl ≈ 768px, matched the previous
DrawerPanel xl=720px). The picker now renders independently of the
push-slot and can safely appear over any DrawerPanel without
collateral-closing it.

Also tighten the CanvasPage Schedule button's disabled tooltip to
explain why it doesn't open while the workflow is unsaved — addresses
the third symptom in the issue ("Workflow button doesn't open the
window at all"): the button was correctly disabled but the tooltip
just said "Scheduler" so the disabled state looked like a broken
button.

- crates/librefang-api/dashboard/src/components/ui/ScheduleModal.tsx
- crates/librefang-api/dashboard/src/pages/CanvasPage.tsx
- crates/librefang-api/dashboard/src/pages/SchedulerPage.test.tsx
  (regression test: opens cron picker, asserts the create-form body
  stays mounted; fails on baseline, passes with the fix)

Verification:
- pnpm typecheck: green
- pnpm build: green
- pnpm test --run src/components/ui/DrawerPanel.test.tsx
    src/components/ui/PushDrawer.test.tsx
    src/pages/SchedulerPage.test.tsx
    src/pages/HandsPage.test.tsx
    src/pages/WorkflowsPage.test.tsx — 42/42 pass
- Pre-existing test infra issue in ModelsPage.test.tsx (Zustand persist
  storage.setItem in jsdom) is unrelated — fails on baseline too.

Closes #5247

* fix(dashboard): keep cron picker above PushDrawer mobile overlay + i18n key (#5247 follow-ups)

Review follow-ups for #5254:

- Modal default zIndex is 50; PushDrawer mobile overlay is z-[55]. After
  switching ScheduleModal from DrawerPanel to Modal in #5254, opening
  the cron picker from inside a drawer on <lg viewports rendered the
  picker BEHIND the drawer overlay, invisible to phone users. Pass
  zIndex={70} on the panel-right Modal — above the mobile drawer (55)
  and OfflineBanner (60), still below notification dropdowns (90/100)
  and ConfirmDialog (150). On lg+ the host drawer is a flex <aside>,
  so any z >= 50 works; no desktop change.

- Add the new "canvas.save_before_schedule" key to en.json and zh.json
  per project convention. The PR was relying on the defaultValue
  fallback, which left the disabled-Schedule-button tooltip
  un-localized for Chinese users.

- Extend the #5247 regression test to also assert the picker's outer
  z-index is >= 56 so the mobile rendering bug above can't silently
  come back. Verified the assertion fails when zIndex is omitted.

* fix(dashboard): keep parent drawer open when Esc fires inside nested picker (#5247 Codex P2)

PushDrawer's window-level Escape handler was treating the drawer-root
as the *outermost* role=dialog ancestor and ignoring the fact that
nested dialogs (the cron picker's Modal, ConfirmDialog, etc.) might
sit between the focus target and the drawer-root. On <lg viewports the
drawer-root *is* a role=dialog, so the previous check —

    target.closest("[role='dialog']")
      && !target.closest("[role='dialog'][data-drawer-root]")

— matched the drawer-root for the second clause whenever the picker
was open inside the drawer, the guard returned false, and the handler
called triggerClose(). Esc from inside the cron picker tore the
surrounding create-schedule drawer down before the Modal could
dismiss itself.

Narrow the check to the *nearest* dialog ancestor: only close the
drawer when target's nearest role=dialog is the drawer-root itself.
Nested dialogs get first crack at Esc, as they should.

Regression test in PushDrawer.test.tsx forces mobile via matchMedia
spy, embeds a role=dialog inside the drawer body to simulate a
nested Modal, scopes the picker-input lookup to the drawer-root
subtree (PushDrawer renders content.body twice — once in the
desktop aside, once in the mobile overlay — and the bug only
exercises in the mobile copy), dispatches Esc at the nested input,
and asserts the drawer store is still open. A positive control
asserts plain-body Esc still dismisses the drawer.

Verified the test fails on the old condition and passes on the new
one (TDD discipline).

* style: apply cargo fmt rescue for sidecar adapter files merged from main

The Quality CI job (cargo xtask fmt -> cargo fmt --all --check) was
red on this PR because the sidecar files merged in from main via
#5252 (3d1e837) carried fmt drift — wrapped multi-line function
signatures rustfmt wants flattened to a single line, and a use-import
ordering tweak in channels.rs. The drift came in with the merge, not
with our scheduler changes, but CI runs against the branch tip so the
red shows up against our PR.

Fix by running `cargo fmt -p librefang-channels -p librefang-api`.
Pure mechanical rewrap — no behaviour change.

* fix(deps): clear brace-expansion 5.0.5 audit advisory (GHSA-jxxr-4gwj-5jf2)

The Security CI job (cargo xtask deps --audit --web) was failing on
the dashboard pnpm-audit step: openapi-typescript >
@redocly/openapi-core > minimatch resolved [email protected],
which is in the GHSA-jxxr-4gwj-5jf2 vulnerable range
(>= 5.0.0 < 5.0.6 — "Large numeric range defeats documented `max`
DoS protection", moderate).

Add a pnpm override for the v5 range, matching the pattern of the
existing v2 override added in #4227 (`brace-expansion@>=2.0.0 <2.0.3:
'>=2.0.3'`). [email protected] is a patch bump and ships in the
same 5.x line as the resolved version, so no semver-major surface
change.

Lockfile delta is intentionally minimal — `pnpm update brace-expansion
--recursive --lockfile-only --depth 999` only touches the
brace-expansion resolution and the one `[email protected]` consumer that
depends on it, leaving the rest of the lockfile untouched. Audit clean
after the change (`pnpm audit` returns "No known vulnerabilities
found").

---------

Co-authored-by: vip <[email protected]>