[AGENT] Improve checkpointing: persist progress after each sub-phase

[jthDEV]

Problem

Checkpoints are only written after a full phase completes. If a scan is interrupted mid-phase (timeout, crash, Ctrl-C), all progress is lost and the scan restarts from scratch.

This is particularly painful for large codebases (8000+ files) where a single scan can take 15-20 minutes. Any interruption means repeating the entire run.

Current behavior

The checkpoint in .sandyaa/checkpoint-<hash>.json is written at phase boundaries. Within a phase (e.g. during recursive verification or POC generation), no intermediate state is persisted.

Expected behavior

Checkpoint should be updated incrementally:

1. After file prioritization — save the prioritized file list so re-runs skip the AI-powered prioritization
2. After each chunk's detection — save found vulnerabilities per chunk, so completed chunks are not re-analyzed
3. After each vulnerability's recursive verification — save verification status per finding
4. After each POC generation attempt — save POC result (success, refusal, or error) per finding
5. After SARIF generation — save that the report was written (avoid duplicate writes on resume)

Key files

• src/utils/checkpoint.ts — Checkpoint persistence logic
• src/orchestrator/orchestrator.ts — Main pipeline, calls checkpoint at phase boundaries
• src/recursive/recursive-strategy.ts — Recursive verification (8 strategies per finding)
• src/agents/agent-executor.ts — POC generation

Acceptance criteria

• Interrupted scan resumes from the last completed sub-step, not from scratch
• Checkpoint file is updated after each of the 5 stages listed above
• Resume correctly skips already-verified findings and already-generated POCs
• No duplicate findings or POCs on resume
• Checkpoint format is backwards-compatible (old checkpoints still work, just resume from phase level)

Context

The tool was designed as a CLI that runs uninterrupted. Now that it's also used as a Claude Code skill (with background task timeouts) and in CI pipelines, robust resume is essential.

[jthDEV]

Additional requirements (from discussion)

1. Memory file instead of monolithic checkpoint

Instead of writing a single checkpoint JSON at phase boundaries, use an append-only memory file (.sandyaa/scan-log-<hash>.jsonl). Each completed sub-step appends one line:

{"step": "prioritize", "result": {"high_priority_count": 65, "files": [...]}, "ts": "..."}
{"step": "detect", "chunk": 1, "result": {"findings": [...]}, "ts": "..."}
{"step": "verify", "finding_id": "CTAE-001", "result": {"status": "verified"}, "ts": "..."}
{"step": "poc", "finding_id": "CTAE-001", "result": {"status": "success", "language": "javascript"}, "ts": "..."}

On resume: read the file, replay completed steps, continue from the first missing one. This is more robust than a monolithic blob — partial writes don't corrupt earlier state, and it doubles as a debug/audit trail.

2. Dynamic concurrency for parallel analysis

Currently concurrency=4 is hardcoded. Replace with dynamic sizing:

const os = require('os');
const cpuCount = os.cpus().length;
const maxConcurrency = Math.max(2, cpuCount * 2 - 2);  // headroom for orchestrator
const concurrency = Math.min(maxConcurrency, Math.ceil(filesToProcess / chunkSize));

This maximizes throughput on beefy machines while staying conservative on small ones. The files / chunkSize lower bound avoids spawning more workers than there is work.