fix(daemon): preserve disabled UI on manual start

[vincentkoc]

What does this PR do?

A cold daemon start now preserves a saved ui_enabled=false setting. Previously it unconditionally requested UI configuration, rewrote the preference to true, and started the HTTP listener.

An explicit cold --port or --open request keeps its existing UI-enabling behavior. Repeated bare starts report the disabled UI without incorrectly saying a browser request failed, and the configuration hint points to config set ui_enabled true. The configuration docs describe these semantics.

Fixes #2114

Validation

• The new disabled-UI regression failed against the unchanged base and passed with this fix. All seven real-process readiness cases passed, covering cold and warm starts, saved enabled/disabled settings, explicit UI requests, delayed readiness, and foreign-listener rejection.
• scripts/test.sh BUILD_DIR=build/full-tests passed on macOS arm64: 8,022 tests passed, 10 platform skips, plus all prescribed process guards and security/ordering checks.
• git diff --check, formatting, cppcheck, and the NOLINT suppression check passed.
• Full lint is not green: scripts/lint.sh exited 2 with 6,972 repo-wide clang-tidy diagnostics. An exact-path VFS comparison of unchanged and candidate src/main.c produced 125 diagnostics each with the same diagnostic categories; none point to changed lines. The existing main_run_daemon_ctl cognitive-complexity diagnostic increases from 82 to 89, already above the threshold of 25. Tools: Apple clang-format 21, clang-tidy 22.1.8, cppcheck 2.21.0.

Checklist

• Every commit is signed off (git commit -s).
• Tests pass locally.
• Full lint passes (the existing clang-tidy debt is described above).
• New behavior is covered by a test, reproduced before the fix.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.