feat: add current_room sensor from working_status field 6

[clawtom]

Summary

Exposes the current room the Narwal is actively cleaning as a new Current room text sensor in Home Assistant. The room name updates in real-time as the robot moves between rooms.

Source: working_status field 6 (room_id) — confirmed via live capture on Flow 2 (firmware v01.07.16.01). Field 6 changes value as the robot transitions between rooms; cross-referenced against the room list from get_map to resolve the display name.

Changes

• narwal_client/models.py — add current_room_id: int | None to NarwalState; parse field 6 in update_from_working_status(); add current_room_name property that resolves the ID via the cached room map
• sensor.py — add NarwalCurrentRoomSensor entity description
• strings.json / translations/en.json — add current_room sensor strings
• tests/test_models.py — 133 lines of new tests covering field 6 parsing, name resolution, edge cases (unknown room, no map, duplicate room type names)

Behavior

• Sensor shows the display name of the room currently being cleaned (e.g. "Living Room", "Phoebe's room", "Bathroom 2")
• Shows unavailable when the robot is docked, idle, or before the map has loaded
• Uses the same display_name logic as the existing room segment selector — user-assigned names take priority over type-derived names; duplicate type names get numbered suffixes ("Bathroom 1", "Bathroom 2", "Bathroom 3")

Testing

152 tests pass (pytest tests/). 12 new tests specifically for the current room feature.

Closes #21

[sjmotew]

Reviewed. Clean scoped change — 12 new tests, +207/0, reuses the existing display_name resolution from #21. Closes #21.

One thing before I merge: working_status field 6 was confirmed on Flow 2 only. Want to sanity-check that field 6 carries the same semantics on Flow 1 (AX12) before this ships — I'll test on my Flow 1 (firmware v01.07.x) and merge if it parses identically. If field 6 is empty/different on Flow 1, the sensor needs an unavailable fallback so Flow 1 users don't see junk.

Related: blocked-then-unblocks for PR #35 (which also touches Flow 2 state decoding) — let's merge this first since it's narrow.

[sjmotew]

@clawtom — this is still the version of current_room I want. It overlaps @Sean-StarLabs's #59, but yours is standalone, tested, and already closes #21. Merge sequencing for all the overlapping fork work is in #66.

Ask: please rebase after #52 lands (step 4 in #66 — the base_status field audit, which corrects several mislabeled fields in models.py and will touch code near yours). I'll merge this right after.

Separately, two things you found earlier deserve an update:

• start_rooms() crashes Flow 2 — command payload likely incompatible #25 (Flow 2 undock-then-crash) — your hypothesis that the payload structure was wrong was half right. It's the topic: clean/plan/start ignores the room payload entirely and runs whatever plan is stored on the robot, which on a Flow 2 in a bad state looks exactly like your undock-then-nothing symptom. Fix is fix(clean): room cleaning via clean/start_clean with a parameterized CleanParam (#25, #37) #49. Once it's on master, could you retest? You're the only reporter on that specific symptom.
• Bug: Flow 2 room sub-type labels differ from Flow 1 (partial mapping confirmed) #22 (Flow 2 room labels) — your captures were accurate, but the conclusion we drew from them was wrong. fix(rooms): use the app's own RoomType→name strings; drop per-model overrides (#22) #48 shows the labels aren't model-specific at all; the base ROOM_TYPE_NAMES table was shifted from index 5 onward, so Flow 2 looked different when it was really just us being wrong everywhere. My per-model override fix (5b4dac7) is getting deleted. Your report is what surfaced it either way.

[sjmotew]

@clawtom — merging #48 and #51 has put this into conflict; models.py and sensor.py both changed under you. A rebase onto current master should sort it.

This is the rebase point I mentioned in #66, so the target is real now rather than hypothetical. Your current_room sensor is still the version I want over the alternatives — standalone, tested, and it closes #21.

I've also approved CI on the fork PRs, so you'll get actual check results this time.

Separately, if you get a chance: the room-clean fix (#49) is close, and you're the original reporter on #25. A retest on your Flow 2 once it lands would be valuable.

[sjmotew]

@clawtom — one more rebase needed, and then I'm done asking. Sorry.

Today's merges moved models.py and sensor.py under you again: #52 (68b5e0d, base_status field audit), #72 (a3edc57, log flooding), and the #48 reland (17ba151). Master is at 17ba151.

The good news is the churn is over. The room-type table was the thing causing repeated conflicts in this area, and it's now settled with decompiled evidence rather than inference — see #48 and #22. It isn't going to move again. Likewise the base_status field labels are now audited, so models.py should be stable from here.

One thing worth checking while you're in there: #52 added station and consumable diagnostic entities and touched how base_status fields are named. If current_room reads any field that #52 relabelled, the rebase may look clean but be semantically wrong. Worth a glance at the field you're parsing out of working_status field 6 against the new labels.

To restate what I said on 07-27, since it's been a while: this is still the version of current_room I want. It overlaps @Sean-StarLabs's #59, but yours is standalone, already tested, and doesn't drag the rest of the Flow 2 series in with it. It goes in on its own merits.

Once rebased I'll take it straight in — it's not gated on #49 or anything else in the queue.