Implement persistent watch daemon

[subzeroid]

Context

/watch is currently REPL-session-local: each watch runs as an in-process asyncio task and dies when the REPL exits. The sqlite watches table already persists watch registrations, but there is no restart recovery or daemon control surface.

This issue tracks turning watch registrations into a persistent local daemon flow while keeping the existing CLI/REPL UX simple.

Scope

Add a persistent daemon mode for registered watches:

• Restart recovery from the sqlite watches table.
• A one-shot daemon runner suitable for systemd, launchd, tmux, or a user-managed shell.
• Control surface from REPL/one-shot CLI to list, add, remove, and inspect watch state.
• Clear status fields for active/paused/error watches.
• Safe shutdown that does not corrupt sqlite or leave in-flight ticks writing after close.

Constraints

• Keep all state local in ~/.insto/store.db.
• Do not introduce a network service, HTTP API, telemetry, or phone-home.
• Keep the 5-minute interval floor unless tests explicitly lower it.
• Keep HikerAPI/account cost and rate-limit risk visible.
• Unit tests must not require live Instagram.

Initial implementation target

Start with the smallest shippable slice:

• insto watch-daemon run or equivalent daemon entrypoint.
• Load persisted watches rows and tick them with the existing facade/watch logic.
• Update last_ok, last_error, and status in sqlite.
• Document how to run it manually; platform service files can come later.

Acceptance criteria

• Existing /watch, /unwatch, /watching, /diff, and /history behavior stays compatible.
• Daemon mode resumes persisted watches after process restart.
• Tests cover daemon loading, one tick, error state update, and shutdown.
• Docs explain manual daemon usage and limitations.

[subzeroid]

Product framing: use case and volume

Use case: watch-daemon is a local long-running monitor for a small set of important targets. It is not an Instagram scanner. Its job is to keep taking profile snapshots and make /diff useful even after the REPL exits, the terminal closes, or the machine/process restarts.

Useful OSINT changes to capture:

• username / alias history
• biography changes
• external URL changes
• public email / phone changes
• follower / following / media count changes
• avatar / banner hash changes
• recent post id snapshot for provenance and later diffing

Current operating envelope should stay intentionally small:

• max active watches: 3
• min interval: 300 seconds / 5 minutes
• worst case at the floor: 3 targets * 12 ticks/hour = 36 ticks/hour
• one tick currently does roughly one profile read plus one recent-posts read, so expect about 2-3 backend calls per tick
• ceiling estimate: about 72-108 backend calls/hour, or about 1.7k-2.6k calls/day if a user runs 3 watches 24/7 at the 5-minute floor

Recommended real-world default: 1-3 targets with 10-60 minute intervals. For HikerAPI this is primarily quota/cost. For aiograpi this is account-ban and rate-limit risk, so daemon behavior should remain conservative and make the cost/risk visible.

Non-goals for the first slice:

• no broad discovery crawler
• no high-volume watch lists
• no background network service or HTTP API
• no lowering the 5-minute interval floor outside tests
• no hidden telemetry or phone-home

Implementation implication: the first PR should focus on restart recovery and safe ticking of existing sqlite watches rows, not expanding volume or adding new watch sources.