fix: verify source memory DB integrity before backing it up (#2895)

[ruvnet]

Fixes #2895. backupMemoryDb() never ran PRAGMA integrity_check on the SOURCE .swarm/memory.db before snapshotting it, so a corrupt DB was copied forward every night and reported as a clean success, silently rotating the last good snapshot out of the retention window. This adds the same integrity check restoreMemoryDbFromBackup() already runs on the way out, to both the online-backup and byte-copy-fallback success paths in memory-backup.ts: a corrupt/unreadable source is still backed up (a corrupt snapshot beats none), but the file is tagged *.CORRUPT.db (still matched by the existing rotation/restore glob, so it stays discoverable but correctly fails its own integrity check and is skipped by restore), an unconditional console.warn is emitted, and the result now carries sourceIntegrity/sourceCorrupt which runBackupWorker() surfaces into its metrics. Opened by the nightly triage routine — human review required before merge.

---

Generated by Claude Code

[ruvnet]

CI red on this PR is not caused by this diff. Checked the job logs for the failing checks (e.g. "Audit root (critical-blocking)", "graph schema smoke", "memory stats legacy-DB smoke", "neural-trader feature/backtest smoke", "Plugin package install-safety", "plugin-registry signature verification smoke") — all of them fail at the same install step, before any test code runs:

npm install --package-lock-only --ignore-scripts
npm error code ETARGET
npm error notarget No matching version found for @claude-flow/mcp@3.0.0-alpha.10.

This is a pre-existing, repo-wide dependency-resolution failure — @claude-flow/mcp@3.0.0-alpha.10 is pinned in package.json but not currently published to npm — already tracked tonight in #3095, #3101, and #3111 (16 failed jobs on main's own v3-ci.yml for the same reason), and referenced independently in several other PRs' CI this same run. It has nothing to do with memory-backup.ts/worker-daemon.ts.

No fix ported: resolving it means either publishing @claude-flow/mcp@3.0.0-alpha.10 or repinning the dependency — both are release/publish-tooling actions outside this routine's scope (and outside a triage PR's scope generally). Not re-running the failed jobs — the log is unambiguous (ETARGET, not a flake signature), so a re-run would reproduce identically. This PR should re-run cleanly once #3095/#3101/#3111 are resolved upstream on main.

---

Generated by Claude Code