Tracking issue for the rename agreed in #60.

Why

@bruvv pointed out (correctly) in #60 that the name "Ban Shield" overpromises — users interpret "shield" as actually preventing Tesla from banning the car, when in reality the feature is a CAN-broadcast-layer mask that rewrites GTW_carConfig (0x7FF) back to a learned-healthy pattern. It does not:

• Prevent Tesla writing to GTW NVRAM
• Undo Tesla's server-side ban flag
• Stop any of the actual ban mechanisms

The marketing in the name leads to user confusion and incorrect expectations.

Proposed name

"GTW Config Replay" — captures both:

1. The learn step (sample GTW_carConfig on first run when healthy).
2. The replay step (rewrite the bus back to healthy when Tesla pushes a config change).

Open to alternatives. @bruvv suggested "GTW old config logger" but that undersells the active rewriting.

Scope of rename

• fsd_handler.h/c — state field ban_shield → gtw_config_replay
• fsd_handler.h/c — function names (handle_ban_shield_* etc.)
• Flipper Settings UI label
• ESP32 web dashboard UI label
• NVS key migration (existing users' ban_shield key must map to the new key on upgrade — one-time migration on first boot of new firmware)
• README.md — feature section + features table
• HARDWARE.md — any reference
• CAN IDs table reference
• FAQ in README that mentions Ban Shield

Migration

Existing users' ban_shield = true setting must continue working on the new firmware. NVS upgrade path: on first boot of vN+1, if ban_shield key exists in NVS and gtw_config_replay does not, copy the value and delete the old key.

Target release

Next minor release after v2.14 (likely v2.15 or v2.15.x depending on whether v2.15 main scope lands first).