Show a sensor's identity in both bases, and take either

Reported as bandsaunter using "completely different" identities from a script
that had been watching the same sensors for years.  They are the same
identities.  Their list against this program's:

    14645 = 3935      8677 = 21E5      14717 = 397D
    3542  = 0DD6      10011 = 271B

Five of their eight, matching exactly; the other three simply were not
transmitting during the three seconds of capture I had.  One base is
hexadecimal and the other decimal, and nothing anywhere said so.

The hexadecimal is not arbitrary -- the identity is a bit field with the
channel packed into the top two bits, and that shape is visible in hex and
invisible in decimal, which is why the decoder carries it that way.  But
rtl_433 and everything built on it prints these in decimal, so anybody who
comes to this with their own sensors already written down has the other form,
and being handed a list that looks unrelated to theirs is a poor welcome.

So both are shown wherever a person reads: the live display when there is room
for the column, the report, the sensor list and the spreadsheet.  `bandsaunter
sensors` is the table for correlating two lists and now has them side by side,
with a line saying which is which and why.

Either may be typed at --name.  One case needs care rather than cleverness:
"3935" is a valid identity in both bases and they are different sensors, so
when both are out there it says the identity is ambiguous and asks for the
whole key instead of picking whichever the code reaches first.

A first attempt at the lookup converted a decimal identity to hexadecimal and
matched on that as well as comparing decimals directly.  Both worked, so
neither could be tested apart from the other; the conversion was removed
rather than given a test written backwards from it.

Full suite 2391 passed, checked against five deliberately broken builds.
Built as 2026-09-20_01.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg

README.md

@@ -1842,6 +1842,26 @@ of a hat in a factory — or a different number out of the same hat the next
 time the batteries were changed. It is enough to tell one sensor from another
 and it is no use at all for telling which is which. `1A2B` is not a place.
 
+**The identity is shown in both bases**, because the same number gets written
+two ways. These identities are bit fields with the channel packed above them,
+so this program prints them in hexadecimal where that shape shows; rtl_433 and
+everything built on it prints them in decimal. `3935` and `14645` are the same
+sensor. Anyone arriving with a list of their own sensors already has it in
+decimal and has no reason to convert it, so `bandsaunter sensors` puts the two
+side by side and either can be typed at `--name`:
+
+```
+name        id    decimal  key         model         ch  msgs  last heard
+back fence  3935    14645  tower/3935  Tower 592TXR  A    412  2026-09-20 14:17
+—           271B    10011  tower/271B  Tower 592TXR  B    408  2026-09-20 14:17
+—           21E5     8677  tower/21E5  Tower 592TXR  C    405  2026-09-20 14:16
+```
+
+The one case that needs care is an identity that is a valid number in both
+bases — `3935` is hexadecimal 3935 and also decimal 3935, which are different
+sensors. If both are out there it says so and asks for the whole key rather
+than picking one.
+
 So **press `n` while listening**. The display comes down, the sensors are
 listed with numbers, you pick one and type a name, and it goes back up. The
 receiver keeps running throughout: a slow typist loses a few seconds of
@@ -1856,6 +1876,7 @@ been heard:
 
 ```
 bandsaunter weather --name 1A2B="back fence" --name 5C=shed
+bandsaunter sensors --name 14645="back fence"        # decimal works too
 bandsaunter sensors --name 0311="lightning detector" --note 0311="south gable"
 bandsaunter sensors --forget 93
 ```