fix: persist daemon watches across client disconnects

[LeoLan-Digital]

Summary

Keep project watches alive in permanent daemon mode after the last client session disconnects.

This allows daemon-owned background file watching and indexing to continue independently of client session lifetime.

What changed

• Preserve the physical project watch when the application runs in permanent mode
• Keep non-permanent behavior unchanged
• Allow watcher-triggered background indexing without an active client session
• Retain daemon ownership of watcher-triggered jobs until completion
• Add regression coverage for permanent daemon watch persistence

Tests

Focused daemon application suite:

• 50 passed

Full CLI baseline comparison:

• baseline: 280 passed, 1 failed
• remaining known failure: tests/test_cli.c:1748
• the same failure reproduces on the unmodified baseline and is unrelated to this change

git diff --check passes.

Behavior

Non-permanent applications retain the existing session-scoped watch lifecycle.

Permanent daemon mode now treats the physical watch as daemon-owned rather than session-owned, while project pruning and daemon shutdown still remove the watch through their existing lifecycle paths.

[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.

[DeusData]

Thank you for keeping the change focused on permanent-daemon watch ownership and preserving the non-permanent lifecycle. Session disconnects, watcher ownership, pruning, and background jobs form a sensitive lifecycle boundary, so we need more time to review it carefully. The queue is quite full, but we will come back with grounded feedback as soon as possible.

[DeusData]

Reviewed. The change is sound and the design question it turns on is answered well. Two lint items stand between it and merge, and the second one deserves care rather than the obvious fix.

The ownership shift is the right shape. Treating the physical watch as daemon-owned rather than session-owned only in permanent mode, with non-permanent behaviour untouched, keeps the blast radius to the mode that actually wants it. And you answered the question I would have asked — if the watch outlives the session, who removes it — by leaving project pruning and daemon shutdown as the lifecycle paths that still tear it down. A watch nothing owns is a leak; a watch owned by the daemon in permanent mode is the point.

The two lint failures

clang-format at src/daemon/application.c:3390-3392 — mechanical. git clang-format on the changed lines clears it. Note the CI formatter is the Homebrew LLVM build; a standalone clang-format-20 produces spurious whole-file drift here.

cppcheck: Variable 'watcher_owns_job' is assigned a value that is never used [unreadVariable] at :3460 — please do not fix this by deleting the assignment.

The flag itself is load-bearing: it is read at the if (watcher_owns_job) immediately above, and that read is what makes the unsubscribe conditional. cppcheck is objecting only to the watcher_owns_job = false; that follows the unsubscribe.

The reason to be careful is that this sits inside the for (;;) loop that begins around :3451. If control can re-enter that block on a later iteration with the flag still true, the reset is what stops a second application_job_unsubscribe_locked(job) on the same job — and removing it to quiet the linter would introduce a double-unsubscribe rather than remove dead code.

So the question to settle is narrow: can the loop re-reach that if after taking it once?

• If it cannot — every path through the block breaks or returns — the assignment really is dead and deleting it is correct.
• If it can, cppcheck is wrong here, and the house rule applies: refactor so the intent is visible to the analyser, or keep it with a // WHY: comment explaining the re-entry. Never silence a linter by removing a line that is doing work.

You are much better placed to answer that than I am from the diff, since the loop body is mostly context here.

Otherwise

Your baseline comparison is the right method — tests/test_cli.c:1748 reproducing on the unmodified base is what makes "unrelated" a measurement rather than an assertion. That failure is environmental and well known here; it depends on the coding agents installed on the machine.

Please also rebase: main moved three times yesterday — broken by a duplicate-symbol merge, repaired by #1993, then #1703 landed.