IOS-6: enforce the nav chrome rule — server chip leading, account button trailing-last, mode control pinned

[jpapiez]

Part of #2410 (epic: iOS navigation redesign — A′ · Two Hats, adaptive).
Wave 1. Blocked by #2412 (IOS-0). Edits AttentionView.swift alongside #2419 and InventoryView.swift alongside #2420 — coordinate landing order with those assignees.

Context — the chrome is inconsistent today

Screen	Server switcher	Evidence
Attention	.topBarLeading	AttentionView.swift:1107-1113
Farm	.topBarTrailing	PrinterListView.swift:68-69
Dashboard	.topBarTrailing	DashboardView.swift:74-75
Scan / Tasks / Inventory	absent	—

Same control, three different answers, and missing entirely from half the roots. And there is no account button anywhere in the app today — it is net-new.

The rule (normative — this is what the UI test in #2425 will assert)

• Leading: server chip. Every tab root. Identical position, no exceptions.
• Trailing: account button, always last. Screen actions (filter, search, scan) sit to its left.
• Pinned: the mode control (IOS-1: adaptive shell — Simple vs Two modes, mode control, derivation, Settings → Navigation override #2416) on every root of both modes. No screen may be a dead end.
• Pushed screens: none of the above. Back button and title take over.

Why the account button may live in the nav bar when Attention may not

Recorded so the reasoning survives the next redesign: a nav bar belongs to the current screen. A destination placed there is either duplicated on every screen or vanishes when you leave — which is exactly the bug this epic is fixing. Account survives that test because it is low-frequency and terminal: you go there, you do one thing, you come back. That is the same slot iOS gives the profile on a tab root in App Store, Music, and Photos. Attention fails it on every count — high frequency, deep destination with its own feed/filters/detail stack, and a badge that would drop from a system-standard always-visible tab badge to a non-standard glyph badge. Attention stays in the tab bar. See #2410 non-goals.

Scope

1. Consolidate the server switcher to .topBarLeading on every tab root, including the three that lack it.
2. Add the account button — the first one in the app — at trailing-last on every tab root.
3. Order all existing trailing screen actions to sit left of it.
4. Ensure no pushed screen carries the switcher, the account button, or the mode control.

The account area is the new home for Settings, Notifications, Manage Servers (re-homed by #2419) and the Offline Queue (re-homed by #2420). This issue owns the button and the container; those issues own moving their content into it.

ServerSwitcherMenu already supports a style: parameter (ServerSwitcherMenu(style: .toolbar)) and ServerSwitcherViewModel.isVisible already suppresses it for single-server installs — reuse both rather than adding a new visibility rule.

Acceptance criteria

• Server switcher is .topBarLeading on every tab root in both shells and both modes, and its existing single-server suppression still applies.
• An account button exists at trailing-last on every tab root, with a stable accessibility identifier agreed with TEST-1: migrate UI-test accessibility identifiers for the new shells #2424.
• Every pre-existing trailing action is repositioned to the left of the account button; none is lost.
• No pushed screen renders the server chip, the account button, or the mode control.
• The account area hosts Settings, Notifications, Manage Servers, and the Offline Queue once IOS-4: delete the ⋯ overflow menu and re-home all 14 orphaned destinations #2419 and IOS-5: remove the Scan tab and re-home every scan sub-flow, including the Offline Queue #2420 land. Until then it must not render broken or empty rows.
• Inventory's scan icon (IOS-5: remove the Scan tab and re-home every scan sub-flow, including the Offline Queue #2420) sits to the left of the account button — one scan affordance, correctly ordered.
• All controls meet 44pt minimum targets with accessibility labels and hints, and support Dynamic Type without clipping the nav bar.
• The rule is expressed so TEST-2: chrome-consistency, shell-derivation, and capability-gating tests #2425 can assert it mechanically across every root — prefer a single shared toolbar modifier over per-screen duplication, so a future screen cannot forget.
• xcodebuild build succeeds; PrintFarmerTests pass.

Files to touch

• mobile/PrintFarmer/Views/Attention/AttentionView.swift
• mobile/PrintFarmer/Views/Printers/PrinterListView.swift
• mobile/PrintFarmer/Views/Filament/InventoryView.swift
• mobile/PrintFarmer/Views/Shifts/ShiftTasksView.swift
• mobile/PrintFarmer/Views/Dashboard/DashboardView.swift
• mobile/PrintFarmer/Views/Components/ServerSwitcherMenu.swift
• New account-area view + a shared root-toolbar modifier

Do not

• Move Attention to the nav bar.
• Give any screen two scan affordances.
• Add the mode control to a pushed screen.

[github-actions]

📋 Assigned to 📱 Hudson (iOS Developer)

Issue: #2421 — IOS-6: enforce the nav chrome rule — server chip leading, account button trailing-last, mode control pinned

📱 Hudson will pick this up in the next Copilot session.

For Copilot coding agent: If enabled, this issue will be worked automatically.
Otherwise, start a Copilot session and say:
📱 Hudson, work on issue #2421