Say something the first time the device sends something we do not read

[matuszeg]

Two of the three message types in #13 are now decoded, from the shim's 14-day access log and the pcaps rather than from guessing.

GET /tm is a clock sync. The vendor answers {"utctime":1786659941836}. It fires on the four-hourly re-auth beat and in the device's reconnect burst, 516 times in 14 days, and it explains why the device's own timestamps sit within a second of ours.

POST /pump_outlet_alerts is not a pump event. All 12 occurrences in the same 14 days land inside that reconnect burst, in the same second as /tm, /oauth/token and /bbs_parameters. The one captured body is idPumpAlertType: 105, recordNumber: 0, value: 0 and the vendor replies {"numRows":-1}, so it reads as "nothing to report" for an outlet subsystem this hardware may not have. Type 3 pings were already decoded in the issue as motor current in amps.

No entities for any of them, which is the decision #13 asked for. Type 3 duplicates mamp, which we already record and already distrust after two identical self-tests reported 5.54 A and 11.83 A. Alert 105 carries a zero. /tm is a request for data rather than data.

What they do earn is being noticed. Pump alerts have parsed cleanly for months and then been dropped without a word; unread ping types vanish inside a comparison in apply_ping; the unknown-field warning was at INFO, which the live install never prints because it logs this integration at WARNING. core/novelty.py now warns on the first sighting of an unfamiliar path, ping type, alert type or bbs_json field, and drops to debug for every one after it. Loud enough to survive a production log level, quiet enough not to nag about something that arrives daily, and it doubles as a firmware-change alarm.

Two cases it deliberately stays quiet about. The four paths we answer rather than read (/tm, /oauth/token, /new_firmware, /bbs_parameters) are mapped, not mysterious, and warning about them would fire on every healthy install. And a body that failed to parse arrives here looking exactly like a path with no parser, so it is excluded by name: the parser has already warned about that, and "nothing here reads /bbs_json" would be false.

Also moved: parse_bbs_json used to log unknown fields itself and now carries them on the reading instead, so one thing decides what is worth saying and says it once.

Verified beyond the unit tests: the end-to-end test drives a real captured pump-alert body through the listener over a socket, twice, and asserts exactly one warning comes out. The cadence figures above are from /var/log/nginx/pumpspy.log on the shim, and the /tm response body is read out of pit_all.pcap.

Closes #13