refactor(claw): the calendar table is the one truth — live, not config

Same move as the watches, and the config's last piece of integration
state goes with it:

- `rhema-calendar-integration` owns the calendar table now
  (`store.rs`): SQLite in the shared dispatch database, the pattern
  the claw's watch table established. `CalendarWatch` gains the
  `validate` the config's boot check used to run — per-kind URL and
  credential rules, plus the lead-under-horizon check — so an invalid
  calendar is loud at the one door every writer shares.
- `CalendarSource::from_store` reads the table fresh on every detect
  pass (the forge source's pattern): a calendar added over the route
  is live next tick, a removed one stops polling, no restart in the
  story. The static constructor stays for tests.
- `POST/DELETE/GET /v1/calendars` on the daemon: the POST body is the
  integration's `CalendarWatch` shape, validated at the table; DELETE
  takes `?name=`; the api listing names the door.
- `ClawConfig.calendars` is gone. A config still carrying it is
  refused at parse time, like the retired `watches:` seed. The
  config-side validation and its tests moved with the type.

The config file now carries only what boot needs: credentials, the
surface, paths, the poll cadence. Everything the daemon reconfigures
at runtime lives in its tables, behind its HTTP doors.

integrations/rhema-calendar-integration/Cargo.toml

@@ -12,6 +12,7 @@ authors.workspace = true
 publish = false
 
 [dependencies]
+rusqlite = { version = "0.40", features = ["bundled"] }
 # The reminder source: one `Source` over the feeds, detect-pass shaped
 # like the task scheduler's
 rhema-autonomous-agent = { path = "../../crates/rhema-autonomous-agent", version = "0.1.0" }