Gate -DPYXIS_TEST_HOOKS behind a dedicated test env

[torlando-tech]

Surfaced by the greptile review on #26 (run details captured in 80 Assistant/Agent Plans/pyxis-pr26/REJECTIONS.md). Suggestion was REJECTED for that PR's scope but the underlying concern is real.

Problem

platformio.ini currently defines -DPYXIS_TEST_HOOKS in both [env:tdeck-bluedroid] and [env:tdeck] build_flags. The flag gates the entire T:* serial command surface (T:DEST, T:SEND, T:SCREENSHOT, T:SHOW, T:CALL_*, T:BLE on|off, etc — see docs/serial_commands.md). Any release binary built from either of those envs ships with that surface enabled.

For development this is fine — the harness needs the hooks, and the prod surface is just a normal serial CDC channel. But shipping a binary to users-as-users means anyone with USB-CDC access can drive announce / send / call / BLE-toggle / screen-switch behaviour on the device. That's a wider attack surface than release needs.

Suggested resolution

Move -DPYXIS_TEST_HOOKS into a new [env:tdeck-test] (and [env:tdeck-bluedroid-test] if needed) that extends from the corresponding production env. Production env strips the flag. Then:

• Dev workflow: pio run -e tdeck-test — full T:* surface.
• Release workflow: pio run -e tdeck — no T:* commands, no test-mode TCP host override, smaller binary, smaller surface.

Acceptance

• pio run -e tdeck produces a binary with PYXIS_TEST_HOOKS undefined; T:* commands respond T:ERR unknown cmd (or are entirely absent from the dispatcher).
• pio run -e tdeck-test keeps the current behaviour.
• .env.example updated to mention the new env name.
• docs/serial_commands.md calls out which env enables the surface.