docs: a scripted browser's aircraft count is not the map's health

[Babissimo]

The live-map check in CLAUDE.md is the one green tests cannot stand in for, so it matters that its most visible number is the one an automated session gets wrong.

Verifying #272 on production, the map read 0 aircraft while the server held 32. Nodes, basemap and controls all rendered, there were no console errors, and the page's own origin served /api/radar/data/aircraft.json a 200 with 108 KB of aircraft. The toolbar count comes from the map's update loop, which a scripted session does not always drive.

Recorded because the failure is indistinguishable from the real thing at a glance: read as a broken deploy, it sends someone chasing a fault that is not there. The note points at aircraft_on_map in /api/test/dashboard as the reliable check, and keeps the caveat narrow — a blank map is still worth chasing, since nodes and basemap do render.

🤖 Generated with Claude Code

[claude]

Claude finished @Babissimo's task in 26s —— View job

---

Review complete

• Gather context (PR diff, CLAUDE.md changes)
• Run code review
• Post findings

Verdict: LGTM. No issues found.

This is a docs-only addition (8 lines to CLAUDE.md), and the specifics check out against the current codebase:

• aircraft_on_map is a real field returned by /api/test/dashboard (backend/routes/test.py:131, surfaced in dashboard/src/types.ts:74).
• /api/radar/data/aircraft.json is a real route (backend/routes/radar.py:100) that the map's own fetch hook calls (frontend/src/components/map/hooks.ts:247).
• The new bullet follows the existing list's voice and bold-lead-sentence convention, and it narrows the caveat appropriately (a blank map is still a real signal; only the toolbar aircraft count from a scripted session is unreliable).

Nothing to change here.