Add hall sensor circuit design, NTAG5 config check tool, I2C bus docs

- Hall sensor + LP5562 EN wired-AND circuit design (DRV5032FB/FE,
  1M pull-up, open-drain topology) with three interaction modes:
  boot-time recovery, tap-to-swap, hold-to-confirm recovery
- NTAG5 config check tool (tools/ntag5_config_check.py) using
  uFCoder library for ISO15693 transparent mode via uFR Zero reader.
  Supports inventory + addressed mode for multi-tag fields.
- Updated DEVELOPMENT_PLAN with I2C bus management notes for
  LP5562 (0x30) + NTAG5Link (0x54) shared bus
- Updated README with wired-AND hardware diagram, hall sensor
  interaction section, and updated wiring table
- Updated CLAUDE.md with LP5562 EN wired-AND topology docs
- Updated STATUS.md with hall sensor decisions and hardware inventory

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/DEVELOPMENT_PLAN.md

@@ -80,6 +80,12 @@ This gives us real pattern data to inform the EEPROM storage format later (M5),
 
 **Important**: The MCU accesses NTAG5Link as a standard I2C slave at address 0x54 — plain register read/write. This is NOT the NFC-side ISO15693 custom commands used by the Python ntag5sensor tooling.
 
+**I2C bus management**: LP5562 (0x30) and NTAG5Link (0x54) share the same I2C bus (A4/A5). Both addresses are used simultaneously — the MCU talks to each device by its address. Key considerations:
+- Both are I2C slave devices with non-conflicting addresses
+- LP5562 engines run autonomously after programming — no ongoing I2C traffic needed
+- Pause LP5562 engines (set exec to Hold) before lengthy NTAG5 I2C transactions to avoid any bus contention edge cases
+- NTAG5Link's use_case must be set to `i2c_slave` (not `i2c_master`) so it doesn't drive the bus
+
 **Tasks**:
 1. Write `src/ntag5/mod.rs` — `Ntag5Link<I2C>` struct, generic over `embedded_hal::i2c::I2c`
 2. Write `src/ntag5/registers.rs` — register map constants from `ntag5link.py`
@@ -182,24 +188,37 @@ Typical 3-engine pattern: 16 + 3×34 + 4 = **122 bytes** (fits easily in 2048B E
 | LP5562 quiescent | ~0.5mA | ~0.5mA |
 | LP5562 LEDs (4ch @ 3mA) | ~12mA | ~12mA |
 | NTAG5Link | ~100µA | ~1µA |
+| Hall sensor (DRV5032) | ~1.6µA | ~1.6µA |
+| EN pull-up (1M @ 3V) | ~0 | ~0 (3µA only when EN low) |
 | **Total** | **~17mA** | **~12.5mA** |
 
 Key insight: LED current dominates. MCU sleep saves ~4mA. Total must stay under EH max (~12.5mA), so LED current must be limited.
 
 **Done when**: MCU sleeps after boot, LP5562 runs patterns, MCU wakes on NFC to accept new pattern.
 
-### M8: Recovery Mode
+### M8: Recovery Mode + Pattern Swap
 
-**Goal**: Hall sensor provides safe mode entry for post-implant recovery.
+**Goal**: Hall sensor provides pattern cycling (tap) and safe mode entry (hold + confirm).
+
+**Circuit**: Wired-AND on LP5562 EN — hall sensor (open-drain) + MCU GPIO (open-drain) + pull-up resistor. Magnet presence forces EN low at hardware level, independent of MCU state. Hall output also connected to MCU EIC pin for interrupt/wake. See `docs/plans/2026-03-03-hall-en-design.md`.
+
+**Interaction model**:
+- **Boot-time recovery**: Hall asserted at power-on → EN held low (hardware), MCU skips EEPROM, loads default pattern, stays awake
+- **Tap (<1s)**: LEDs off instantly (hardware EN drop) → magnet removed → MCU loads next pattern → LEDs back
+- **Hold (>3s + confirm)**: LEDs off (hardware) → magnet removed → MCU blinks warning (3x red) → 2s window for confirmation tap → if confirmed, enters recovery mode. No second tap → resumes normal operation
+- **MCU crashed + magnet**: Hall still kills EN (hardware safety)
 
 **Tasks**:
-1. Wire hall sensor to EIC-capable GPIO pin
-2. Boot-time check: if hall sensor asserted → recovery mode
-3. Recovery behavior: load hardcoded solid white (low brightness), skip EEPROM, stay awake
-4. Set recovery flag in SRAM so phone app can detect it
-5. Add hall sensor as runtime EIC wake source (e.g., cycle patterns)
+1. Wire hall sensor: open-drain output to EN line (wired-AND) + separate wire to EIC pin
+2. Add pull-up resistor (100k-1M) on EN line
+3. Configure MCU GPIO (D0/A0) as open-drain for EN control
+4. Implement EIC interrupt handler for hall sensor pin
+5. Implement boot-time recovery: read hall GPIO at startup, if asserted → default pattern, skip EEPROM
+6. Implement runtime state machine: tap detection, hold timing, warning blink, recovery confirmation
+7. Recovery behavior: load hardcoded solid white (low brightness), skip EEPROM, stay awake
+8. Set recovery flag in SRAM so phone app can detect it
 
-**Done when**: Holding magnet near hall sensor at boot triggers recovery mode with default LED pattern.
+**Done when**: Boot-time recovery works (magnet at power-on), tap cycles patterns at runtime, hold + confirm enters runtime recovery, hardware EN kill works even if MCU is unresponsive.
 
 ### M9: Power Characterization
 
@@ -272,7 +291,7 @@ Deferred until Groups A-D are solid.
 | Risk | Severity | Mitigation |
 |------|----------|------------|
 | Power budget too tight for 4ch LED | High | Limit current to 2-3mA/ch, use pulsed patterns, run fewer channels |
-| I2C bus contention (LP5562 + NTAG5) | Medium | Pause LP5562 engines before NTAG5 I2C access, resume after |
+| I2C bus contention (LP5562 + NTAG5) | Medium | Non-conflicting addresses (0x30 vs 0x54). Pause LP5562 engines during NTAG5 I2C bursts. Verify NTAG5 is in i2c_slave mode (not i2c_master) |
 | EEPROM write endurance (~100K cycles) | Low | SRAM for transient comms, EEPROM only for pattern persistence |
 | Boot time too slow | Low | Estimated ~15-20ms — appears instant to user |
 | NFC coupling distance too short | Medium | Optimize antenna, low field strength EH mode, accept 1-3cm |