Keep the local daemon bound to loopback

[CoreyRDean]

Non-technical summary

This closes the remaining gap where the local llamafile-local daemon could be pointed at a non-loopback bind host through config. After this change, the daemon-managed local model endpoint stays local-only by contract, and users get an explicit error instead of silently exposing it more broadly.

Why this matters now:

• INTENT.md says the project is local-first by default.
• The daemon architecture already describes the managed model server as loopback-only.
• Issue Restrict daemon traffic to local host only #14 identified that config still allowed broader host binding despite that intent.

How the system is better afterward:

• daemon.host now accepts only loopback values.
• llamafile-local refuses invalid host config instead of falling back or binding wider than intended.
• The config and spec surfaces now describe the real security boundary.

Technical summary

• Add a shared local-daemon host resolver in internal/cli that canonicalizes accepted loopback values (127.0.0.1, localhost, ::1) to 127.0.0.1.
• Use that resolver in both daemonRunForeground and buildBackend("llamafile-local", ...) so startup and local backend resolution enforce the same boundary.
• Reject invalid daemon.host values in i config set so the user gets fast feedback before a bad config lands.
• Add regression tests for host normalization, local backend rejection of non-loopback hosts, and CLI smoke coverage for config set daemon.host 0.0.0.0.
• Update docs/SPEC.md so the configuration example and daemon contract match the implementation.

Relevant intent being strengthened:

• INTENT.md: local-first by default, safe by construction.
• internal/daemon/daemon.go architecture comment: the daemon-managed HTTP API is on loopback.
• Issue Restrict daemon traffic to local host only #14: restrict daemon traffic to local host only.

Tests:

• go test ./internal/cli/...
• go test ./...
• go vet ./...
• make build

Breaking changes:

• Users who previously set daemon.host to a non-loopback value for llamafile-local will now get a validation error. This is intentional: remote serving belongs on the explicit network backends, not the local daemon path.

Additional notes

Trade-off:

• The change deliberately canonicalizes accepted loopback values to 127.0.0.1 rather than preserving the original spelling, because the goal here is enforcement and a single predictable local endpoint, not host-style fidelity.

Deferred follow-up:

• This does not change the explicit network backends (llamafile-network, ollama, openai). Those remain the supported surfaces for non-local endpoints.

Remaining gap:

• This closes the daemon bind-host hole, but it does not add broader daemon hardening like auth or proxy-layer restrictions, which would be separate increments if the architecture grows beyond local-only use.