feat(schedule): add deterministic one-shot scheduler execution

[CrisSTEM]

Summary

Add a deterministic one-shot scheduler flow that selects due schedule jobs from configured cadences, executes work through the existing fetch runtime, and persists execution outcomes in schedule_runs.

Linked issue(s)

• Closes feat(schedule): add deterministic one-shot scheduler execution from configured cadences #47

Milestone fit

This PR delivers the v0.4.0 one-shot scheduler slice on top of the existing processing storage contracts. It keeps scheduler behavior deterministic, config-driven, and reviewable while explicitly deferring daemon/process-supervision/API concerns.

What changed

• add a new internal/schedule runtime for due/not-due selection, persisted schedule_runs, and mixed success/failure handling
• extend the fetch runtime with a source_id filter so scheduler execution can reuse the existing ingestion path instead of introducing a parallel fetch path
• add signalscope schedule --config <dir> --db <path> [--job <schedule-job-id>]
• add deterministic runtime and CLI tests for due/not-due behavior, partial failures, total failures, and job filtering

Out of scope

• daemon behavior, cron deployment, or process supervision
• distributed locking
• API exposure of scheduler state
• notification delivery
• broad reviewer-flow documentation updates beyond the runtime surface (tracked separately)

Validation

Mark what you actually ran:

• python3 ./scripts/trim-whitespace.py --check
• go vet ./...
• go test ./...
• make ci
• Manual CLI verification was performed if runtime behavior changed

Documentation impact

• No docs update needed
• README.md
• SPEC.md
• docs/
• repository governance docs (AGENTS.md, CONTRIBUTING.md)
• CHANGELOG.md
• release notes

Reviewer focus

Call out the highest-risk files, behaviors, or assumptions to review.

• internal/schedule/runtime.go
• internal/fetch/runtime.go
• internal/cli/app.go
• due/not-due semantics based on the latest terminal schedule_runs.started_at + cadence
• honest mixed-outcome behavior when some downstream fetch work fails

Auditability checklist

• Branch name follows project convention
• PR scope matches the linked issue and milestone
• Commits were pushed progressively, not as one final dump
• Relevant tests were added or updated for behavior changes
• No secrets or sensitive credentials were introduced
• Deferred follow-up work is documented explicitly
• Unimplemented work is not implied as completed

Notes for merge

Preferred merge method:

• Issue PRs: Rebase and merge
• Release aggregation PRs: Merge commit
• Use Squash and merge only when the branch became noisy and preserving intermediate commits no longer adds value