[fujibee]

Daemon startup can leave an owner in starting when a CLI reader briefly holds install.db: the entrypoint bypassed the shared SQLite busy timeout, so markReady() could throw database is locked. Use the verified shared openInstallDb() for the claim connection, and give the bootstrap read-only connection the same five-second bounded wait. Operation-lock probes remain nonblocking.

An immediate stop also exposed ReferenceError: Cannot access 'timer' before initialization at doStop() in captured daemon stderr. Declare the polling timer before startup so the control handler can stop safely before interval initialization.

Add an entrypoint regression that synchronizes a separate read transaction at the ready-write boundary. The second-start CLI test now prints daemon logs on failure for both starts. The #1529 failure at line 189 was the first start; the second start had not executed. The original CI exception was not captured, so the reproduced SQLite race is a confirmed defect rather than a proven attribution of that CI failure.

Validation: the new regression fails on the original entrypoint with database is locked at markReady(), and passes with the fix. All four entrypoint bats tests, seven relevant daemon CLI bats tests, and thirteen database/owner/main Node tests pass on macOS. Local bats verification used a scratch helper copy with HOME reassignment and directory deletion disabled; resident-manager registration cases were excluded. Linux verification is left to CI.