security: interactive developer SSH reactivates inherited Telnet #645

Summary

A developer SSH session that does not supply a remote command starts the root login shell. BusyBox ash sources the inherited /etc/profile, whose line 21 runs busybox telnetd&. This reactivates unauthenticated TCP/23 after BloomOS has completed its normal listener lockdown.

Observed device evidence

Observed on one Miyoo Mini Plus while validating signed UI-12 candidate 0.1.0-dev-e9ce0c30; its network, developer-SSH, and listener-audit binaries are byte-identical to installed known-good 0.1.0-dev-0b3b5d96.

• root shell: /bin/sh -> BusyBox; /etc/passwd selects /bin/sh
• /etc/profile SHA-256: fc6fcec8bef19104f13a6b57d52b0140b4a70d929e81d86744b95e92375c53a9
• inherited command: line 21, busybox telnetd&
• observed process: busybox telnetd
• observed listener: 0.0.0.0:23
• bloom-listener-audit correctly reported prohibited:["telnet"] and prohibited_processes:["telnet"]
• the exact Telnet PID was terminated; a subsequent independent audit was clean with only reviewed key-only SSH
• Wi-Fi remained associated, the network transaction remained idle, and the signed update remained healthy

The trigger was an operator probe whose quoting accidentally omitted the intended remote command, but an ordinary interactive SSH login has the same login-shell semantics. Non-interactive commands do not source the profile and remain safe.

Required result

• neutralize the inherited Telnet launcher before developer SSH becomes reachable, including interactive/login-shell sessions
• preserve key-only interactive SSH and non-interactive automation
• do not replace or remove the sole automation key
• keep listener reconciliation idempotent and fail closed
• add focused tests proving an interactive login cannot recreate Telnet, plus listener/process/port coverage
• validate on Mini Plus with a fresh independent key-only interactive session, immediate listener audit, clean teardown, and exact rollback evidence

This is a listener-lockdown gap discovered after PR #642; it is not caused by the UI-12 power change in PR #644.