fix(security): harden daemon auth boundaries

[TheusHen]

What changed

This tightens two security edges that are easy to miss in day-to-day use:

• the controller now refuses to start unauthenticated on a non-loopback bind (0.0.0.0, ::, etc.) instead of only logging a warning
• the CLI no longer prints the actual FORKD_TOKEN value in help output when the token is supplied via env

Both keep the local dev path boring: loopback without a token still works, and authenticated network binds still work.

Why

These are trust-boundary footguns:

• a network-exposed daemon without auth is too dangerous to allow by default
• help text leaking bearer tokens is the kind of thing that ends up in logs, terminals, screenshots, and CI output

Checks

• cargo fmt --check
• cargo test -p forkd-cli -p forkd-controller
• cargo clippy -p forkd-cli -p forkd-controller -- -D warnings
• manual: FORKD_TOKEN=pony-secret-token-123 forkd ls --help does not print the token value
• manual: forkd-controller serve --bind 0.0.0.0:8899 without --token-file exits with refusing unauthenticated non-loopback bind