Add multi-AP routing and per-hub storage

[wendefeuer]

Summary

Adds multi-access-point support while preserving one logical Home Assistant device per physical tag.

• allows multiple AP config entries while still rejecting duplicate hosts
• registers AP devices with config-entry-specific identifiers
• routes tag state and actions to an online AP, preferring the freshest last_seen
• keeps shared tag entity/device IDs stable and removes the static via_device link
• separates tag cache storage per AP with legacy migration filtering
• preserves a tag when it is removed or blacklisted on only one AP
• resolves reboot_ap against the explicitly selected AP device
• retains the existing BLE paths
• adds English and German fork installation, rollback, backup warning, changelog, known-limitations, and issue-reporting documentation

Fixes the failure mode described in #335.

Tests

• 9 focused multi-AP tests pass (routing, fallback, freshest check-in, blacklist handling, unique AP IDs, split storage, reboot response)
• Python 3.12 compilation and JSON/translation validation pass
• current full Windows/Pillow run: 36 passed; the same 27 image snapshot failures reproduce on an untouched upstream worktree in this environment
• detect-secrets reports no candidates in the publishable tree
• test fixtures use documentation-only addresses and identifiers; no private deployment addresses or tag IDs remain in the current tree

Live validation

Validated on Home Assistant Core 2026.7.2 with two Yellow APs:

• eight tags were present in both AP databases
• HA exposed two distinct AP devices and one device per shared tag
• drawcustom, LED, clear pending, force refresh, tag reboot, and channel scan selected only the expected AP; the other AP record stayed unchanged
• disabling and re-enabling one config entry preserved fallback routing through the other AP
• reboot_ap was executed successfully against each AP device independently
• all five existing BLE entries remained loaded and a BLE temperature entity continued updating
• separate stores were created for both AP config entries

The AP firmware intentionally restarts before completing the /reboot HTTP response, so a read timeout after an accepted request is treated as successful for that action only.

Fork release and feedback

The public fork publishes the validated Multi-AP implementation as stable fork release 3.0.1 and uses its GitHub Issues as the central feedback channel. Reports should include sanitized logs and must omit tokens, private addresses, tag identifiers, and personal data.