fix: four high findings of the manual review, and the reason for v=6

[angeloINTJ]

Four of the high-severity findings that docs/analysis/PLANO_REVISAO_EXTERNA.md still listed after v2.11.0 (1, 8, 9 and 25), and the reason the Files page did not give for v=6, which v2.11.0 listed under Known. One commit per finding, then the flash record and the plan. Each finding was checked on the rig against main e5438e7 (v2.11.0 and two docs PRs), both images started from the same bench state.

What changes

	main	this branch
9, the forced PIN change (stricter policy, factory 1234)	SAIR opens the Settings menu, PIN unchanged	SAIR goes to the dashboard; Settings asks for the account again
8, permissions granted at the panel	an account with Users gives Limits, Block and Maintenance to anyone, itself included	it adds only bits it holds; taking one away is allowed (panelGrantAllowed, the web's V-09 rule)
1, "Adopt the probe wired here"	reads GP<slot>, writes that number as the slot's pin, no reload	reads and keeps the slot's GPIO, reloads the sensors; 409 for a slot not saved as an active DS18B20
25, the AP opened by the boot gesture	its 15 min limit read 32 bytes nothing had written	beginAP( ) gets the network's name: with one, the AP gives way at 900 s; with none, it stays
v=6 on the Files page	"Upload failed (validation v=6). Cancelled."	adds "The image is for another chip, or it is damaged. The Pico 2 W takes the releasetwo .bin, and the Pico W the others."

The 3 s sensor health check had finding 1's mistake too: it read GP<slot> for each DS18B20 slot. It reads the slot's GPIO now.

Tests first

• native: test_panel_grant_adds_only_bits_the_caller_holds (finding 8). 284 of 284.
• native_network: three cases, 39 of 39. Against main's NetworkManager, called the way main calls it, two fail:
  • test_an_ap_given_the_network_gives_way_to_it fails over a zeroed object: "the AP outlived its limit on a unit with a network";
  • test_the_ap_limit_reads_no_leftover_bytes fails over memory holding 0x01: "leftover bytes closed the AP of a unit with no network";
  • test_an_ap_with_no_network_stays_open passes on both.
• tools/test_webui_firmware_refusal.py: the v=6 reply and the fil_fw_v6 key. Against main's page and packs it fails in 6 places; here it passes.
• All nine native suites pass here, plainly and under ASan and UBSan, as CI runs them. So do the gates job's scripts (check_readme_numbers.py with 636 cases) and build_manual.py --check.
• Every commit builds pico_w_test.

On the rig

For findings 9, 8 and 1, each run used pico_w_test of its own tree, from the S1 bench dump, restored and read back byte for byte before each image. The web is on :8080, the panel is driven with POST /api/touch, and the log is read from /api/logs. Finding 25 ran afterwards on the same unit, from bench builds with the touch remapped.

Finding 9. Tightening the PIN policy from 4/3/0 to 5/3/0 marks every account holding a PIN. pmgr identified with its old 5-digit PIN (code 308), Novo PIN opened on the ordered keypad, and SAIR gave:

• main: UI mode 5, the Settings menu;
• this branch: UI mode 0, the dashboard. CFG then opened the account picker (mode 26).

Finding 8. pmgr holds Users alone (0x0100):

from its Users menu	main	this branch
a new account with L and M	created, 0x1400	refused
ptgt 0x0, plus L	0x0400	refused, 0x0
pkeep 0x0800, minus B (a bit pmgr lacks)	0x0	0x0
pmgr itself, plus M	0x1100	refused, 0x0100
log	450 ×1, 453 ×3	453 ×1, 458 ×3

Finding 1. Two cases:

• Slot 1 on GP1, after a swap. sensor define told the slot it holds slot 0's probe, so it sat in quarantine. Adopt answered 200 on both. Over the next 90 s, main read 0 valid values of 15; this branch read 14 of 14, the first one at once.
• The probe on GP1, moved to slot 7. main read GP7 and answered 422 badrom, for a probe GP1 was reading at 23.7 °C. This branch answered 200, the slot stayed on GP1, and it read again 8 s after the reload.
• An empty slot. On this branch, Adopt on slot 12 answered 409 {"error":"notds18b20"}.

Finding 25. The image is a bench build of pico_w_test with -DTOUCH_IRQ=17 -DTOUCH_CS=21 (AGENTS.md §1). The hand held the finger down across a reset, on a unit configured for the bench network. The event log has, on both images, code 403 with context 1 (the gesture) 10 s into the boot, and code 525, "AP mode timeout, rebooting to STA", at 910 s:

• main: the AP gave way too. The 32 bytes were not zero on that boot, so the rig did not show "never expires". The host tests pin both sides: the zero case for a unit with a network, and the leftover-bytes case for a unit with none.
• this branch: the AP gave way, the next boot joined the network, and the web answered on :8080.

The rig did not try a unit with no network. Neither the console nor the web clears a configured network, so that takes a factory reset.

Flash

image	main	this branch	budget
release	1,020,660	1,020,940 (+280)	1,020,732 → 1,021,012
test	1,025,244	1,025,516 (+272)	holds
test_https	1,030,284	1,030,492 (+208)	1,030,284 → 1,030,492
asserts	1,022,964	1,023,236 (+272)	1,022,996 → 1,023,268
alpha	974,868	974,908 (+40), .bin unchanged	holds
Air	1,018,176	1,018,224 (+48), .bin unchanged	holds
Pico 2 W	996,736	997,000 (+264)	996,864 → 997,128

Budgets move by the growth, which keeps their margins. The signed release .bin has 7,171 B left under the OTA ceiling (7,451 B on v2.11.0). The test image's slack, 2,595 B, was already under one sector.

Three trims kept the growth there, from +472 B on release:

• panelAllowed( ) gets an overload, not default arguments (−56 B);
• beginAP( ) writes the name, instead of the constructor zeroing four buffers (−96 B);
• _pinForced has no initializer (−16 B).

Found on the way, not fixed here

• A stricter PIN minimum locks shorter PINs out of the panel.
  • DisplayManager::pinSubmit( ) refuses an entry shorter than the current minimum before Core 0 sees it.
  • So after 4 → 5, the 4-digit PIN of an account marked to change it cannot identify at all; on the rig it got "PIN muito curto".
  • The comment on user policy says tightening marks the PINs precisely so that this does not happen.
• The message says "(min 4)" in the firmware and in both packs, whatever the policy's minimum is.
• The touch-remapped bench image opened the AP on every boot. With the hand at CHARGER HIZ, the line reads low once the boot's first look is past. CHARGER ON holds it high, and AGENTS.md §1 now says so.

Docs

• Manual chapters 6, 8, 9 and 17 describe the new behaviour; MANUAL.pt-BR.html is regenerated.
• The three READMEs count 636 cases.
• PLANO_REVISAO_EXTERNA.md marks the four findings, 52 remaining.
• tools/flash_budget.json and §3.1 of PLANO_STABLE.md carry the record.
• AGENTS.md §1 notes the trap of the touch-remapped image.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BniVDEDSHGQgcoqmCRn5um