Task: Fix Robot device selection and binding

Identity

Fix the Robot page so the device panel follows the currently selected agent.
Prove that binding a new activation code targets the selected agent while preserving the existing guided/manual binding flow.
Clarify that the current product adds devices through a six-digit activation code; nearby-device discovery remains out of scope.

Treat devices as agent-scoped child resources in the UI while retaining the account-wide overview DTO.
Do not add a new backend route, automatic discovery, firmware behavior, or a second hardware module.
Preserve Main-owned provisioning, activation-code secrecy, idempotency, reassignment revisions, and the default-off guided Hotspot flow.
Use a deterministic page regression test that reproduces the exact stale-device symptom before changing production code.

Task: 20260816-robot-device-selection-f6a2, Feature mode, isolated worktree and branch, base 3b466972.
Read: active task record, planning entry, project memory index, positioning, current state, decision index, system overview, business rules, success criteria, and the completed provisioning/hotspot-binding peer records.
Peer assessment: Guided Hotspot Binding overlaps the same page but is already merged into this base; its state machine and security constraints must be preserved. No active task owns this worktree or is implementing the same selected-agent device seam.
Gate result: Concurrent Task Gate and Planning Gate passed.

Add a red page test with two agents and two devices that asserts the device panel follows the selected agent.
Add a red binding test proving a new activation code is submitted with the selected agent ID.
Filter the overview device projection by selected agent and tighten agent-scoped device copy without changing API contracts.
Run focused tests, typecheck, scoped lint, diff checks, project-document gates, and an independent Sol review.

Reproduced the stale-device bug: the page projected every account device regardless of the selected agent, so changing agents refreshed configuration but not the device panel.
Filtered the device projection by device.agent_id === selectedAgentId; switching agents now changes both configuration and visible devices.
Added an agent-scoped device count to each agent row, matching Xiaozhi's verified deviceCount semantics without adding a new API.
Clarified the device panel, empty state, and binding action as belonging to the current agent.
Made the binding target immutable for the dialog lifetime: it shows the current agent read-only, while the editable agent selector remains exclusive to existing-device reassignment.
Proved that opening the binding flow after selecting the second agent submits the new six-digit activation code with that agent's ID.
Kept existing atomic reassignment, guided Hotspot provisioning, activation-code secrecy, and account-wide overview contracts unchanged. No backend or firmware code was changed.

RED: the new two-agent/two-device page regression failed against the previous implementation because the first agent panel also rendered the second agent's device.
PASS: pnpm exec vitest run tests/unit/ai-hardware-page.test.tsx — 1 file, 39 tests.
PASS: pnpm exec vitest run tests/unit/ai-hardware-page.test.tsx tests/unit/ai-hardware-api.test.ts tests/unit/ai-hardware-routes.test.ts — 3 files, 92 tests.
PASS: pnpm run typecheck.
PASS: scoped ESLint for the changed page and test.
PASS: git diff --check (line-ending warnings only).
Source comparison confirmed Xiaozhi agent cards expose per-agent device totals and device management filters by agent; adding a normal device uses a six-digit activation code. Makelore derives the same count from its safe overview DTO.
Independent Sol review initially returned FAIL with one P1 and one P2: the binding target remained editable and the short aria-label hid the scoped visible action. Both were corrected, the complete focused suite was rerun, and re-review returned PASS with no P0-P3 findings.

Automatic nearby-device discovery and management-side manual MAC insertion remain intentionally unsupported by the public Makelore/Works contract.
A physical multi-device smoke should bind a second real device with its own fresh activation code, switch between two agents, and verify atomic reassignment before the next packaged release.