bug(apps/nats): enabling TLS removes plaintext access, and it is enabled implicitly from external #3348

Enabling TLS on a NATS instance appears to remove plaintext access rather than add TLS alongside it, and TLS is enabled implicitly from external — so publishing an instance externally can sever existing plaintext clients on the next reconcile.

Two parts, both in packages/apps/nats:

1. tls.enabled, when unset, defaults to the value of external (templates/_tls.tpl). An instance that is switched to external: true — or one that already is — therefore gets TLS without anyone asking for it.
2. The rendered server config sets TLS on the client port and never sets allow_non_tls. In NATS that makes port 4222 TLS-only: plaintext clients are not served on a second port, they simply stop connecting.

The consequence is the combination: a change that reads as "publish this instance" also changes the wire protocol for every existing client, with no opt-out short of setting tls.enabled: false before the reconcile.

Confidence and what has not been checked. This is read off the chart and the NATS server's documented behaviour for a tls block without allow_non_tls — it has not been reproduced against a running instance. Before acting on it, someone should confirm on a live instance that a plaintext client is in fact refused once TLS is on. If NATS is serving both somehow, only the implicit-enable half of this stands.

For comparison, the same implicit-enable pattern was recently reconsidered for another engine: where TLS replaces plaintext rather than adding to it, the enablement was made an explicit opt-in precisely so that an upgrade cannot cut live connections. The question here is whether NATS should follow, or whether keeping plaintext available (allow_non_tls) alongside TLS is the better shape.