feat(vigil): core runtime and --vigil-once headless driver (slice 2 of 5)

[allen-munsch]

What

Slice 2 of 5 for the vigil runtime (issue #760, ELEGY-1). This adds the core runtime — triggers (toll/watcher/harbinger), the reaper event loop, rite gate evaluation, commands-mode dispatch, and the VigilKeeper public API — plus the headless --vigil-once driver.

Stacked on top of #810 (slice 1: persistence + dirge vigil CLI), which must merge first. This PR's base is vigil/01-db-cli, so the diff shows only the runtime layer.

Scope

• src/extras/vigil/{mod,types,reaper,toll,watcher,harbinger,rite,dispatch,tests}.rs — runtime modules and their tests
• src/main.rs — keeper startup, wake channel, on-vigil-observance dispatch, --vigil-once headless driver with hook drain
• src/cli.rs — --vigil, --vigil-config, --vigil-once, --vigil-once-command
• Cargo.toml / Cargo.lock — vigil = ["dep:notify"], notify 7 optional
• .osv-scanner.toml — RUSTSEC-2024-0384 ignore for instant (transitive via notify)

Notes / known gaps

• vigil stays opt-in (not in default features).
• Plugin-bridge (vigil_plugin_tx) and TUI observer wiring are deliberately deferred to later slices; the headless path has a live caller, so nothing here is #[allow(dead_code)]-gated beyond the pre-existing vigils_dir() helper slice 3 will consume.
• 33 new runtime tests (45 vigil tests total pass locally), plus fmt/clippy (all-features and windows-default) and both build variants are clean.

Self-review concerns

• The keeper's plugin/observer hooks are stubbed with _ bindings; if the reviewer would rather see those slices land before merging a runtime slice, I can reorder.
• notify 7 is pulled in for watcher; worth a second look at whether pulling a whole watch crate for one trigger type is justified versus a hand-rolled poll.