Store cleanup plans and evidence in Data Machine storage, not filesystem JSON files

[chubes4]

Problem

DMC cleanup workflows still encourage or rely on filesystem JSON plan files for review/apply loops. That is the wrong storage shape for a WordPress/Data Machine plugin.

Observed during workspace cleanup on intelligence-chubes4:

• Operator/agent workflow created /Users/chubes/Developer/.dmc-cleanup-plans.
• The directory accumulated loose JSON plan/apply files.
• It was small in this run (5.2M), but the pattern is wrong: plans can pile up indefinitely, are not queryable from the site, are not tied to Data Machine jobs, and bypass the database/evidence surfaces DMC already has.

Expected behavior

Cleanup plans, chunks, status, and evidence should be stored in Data Machine/WordPress storage, not loose files.

Required shape:

• Dry-run review creates a database-backed cleanup run/plan record.
• Apply references a plan_id / run_id, not --apply-plan=/path/to/file.json for normal operator use.
• Chunk payloads live in Data Machine job engine_data or dedicated cleanup tables/records.
• Evidence is queryable through workspace cleanup evidence <run-id>.
• Retention policy prunes old cleanup plan/evidence records.
• CLI may still accept stdin/file input only as an escape hatch, not as the primary documented workflow.

Current bad shape to remove

• Documented examples that redirect JSON to files.
• Agent/operator workflows that write .dmc-cleanup-plans or /tmp/*.json.
• Any code paths that require filesystem JSON to safely apply a reviewed cleanup.

Acceptance criteria

• Primary docs/help show DB-backed run_id / plan_id flow.
• No .dmc-cleanup-plans convention.
• No filesystem plan retention burden.
• Evidence/status can reconstruct what was planned, applied, skipped, failed, and reclaimed from DB-backed records.

[chubes4]

This should now be implemented as part of the umbrella architecture in #245, with concrete tables from #244. The important architectural line: Data Machine job can carry small chunk-local execution params, but the canonical plan/review/apply/evidence state belongs in DMC-owned DB rows keyed by .

[chubes4]

Correction to the previous comment: this should now be implemented as part of the umbrella architecture in #245, with concrete tables from #244.

The important architectural line:

• Data Machine job engine_data can carry small chunk-local execution params.
• The canonical plan/review/apply/evidence state belongs in DMC-owned DB rows keyed by run_id.
• Filesystem plan files should become an emergency import/export path only, not daily-driving operator state.