stop tracking dynamic bytes that are not buttons

[g4bri3lDev]

Problem

AdvertisementTracker decodes all 11 bytes of the dynamic block as button reports and emits a transition whenever any of them changes.

But only the bytes a BinaryInputs packet claims are buttons. The rest belong to touch controllers and sensors — and because a button report is just button_id | press_count << 3 | pressed << 7, any byte decodes into a valid-looking one. So a moving touch coordinate or a refreshed sensor reading produces phantom button_down / button_up / press_count_changed / button_slot_changed events.

On a reTerminal E1003 (button byte 0, touch 1–5, SHT40 7–9), a 0.1 °C change in the sensor reading is enough:

unfiltered (old behaviour): 1 event(s) [('button_slot_changed', 7)]
filtered   (button byte 0): 0 event(s) []

This is pre-existing and not caused by the SHT40 work in #152 — touch controllers have triggered it since TouchTracker landed. Home Assistant filters incoming events by the configured byte_index before firing an entity, which is why it has been invisible there, but the events were still produced on every advertisement and any other consumer would have believed them.

Fix

AdvertisementTracker now takes the byte indices it should watch:

AdvertisementTracker(
    idx
    for bi in config.binary_inputs
    if (idx := bi.published_button_byte_index) is not None
)

The parameter is optional and defaults to watching every byte, so existing callers are unaffected until they opt in — no breaking change, no major version bump.

BinaryInputs.published_button_byte_index is added so callers don't re-implement the firmware's rule that 0xFF (its default) means "not published", and that indices past the 11-byte block are ignored.

AdvertisementData.button_events is left decoding every byte — it's the raw primitive — but its docstring now says so explicitly, since that is what made the tracker wrong.

Verification

979 tests pass; ruff, ruff-format, mypy strict and pylint clean. New coverage:

• a non-button byte changing emits nothing
• a configured button byte still emits button_down + press_count_changed
• multiple watched bytes
• an empty index set emits nothing
• omitting the argument preserves the old watch-everything behaviour
• published_button_byte_index for 0, 10, 0xFF and an out-of-range index

Follow-up

Home Assistant should pass the indices when constructing the tracker in coordinator.py; until it does, behaviour there is unchanged. Worth doing in the same pass as the SHT40 sensor entities so it rides one manifest bump.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!