Emergency cleanup task persists megabyte reports in every log and job

[chubes4]

Problem

WorkspaceDiskEmergencyCleanupTask embeds the complete emergency cleanup report twice on every recurring run: once as datamachine_log context and again as terminal job engine_data.

On a live local workspace this produced:

• 270 info logs consuming about 350 MB of a 414 MB datamachine_logs.json snapshot.
• Individual log contexts of 1.2-2.1 MB; the report field accounts for effectively the entire payload.
• 744 completed workspace_disk_emergency_cleanup jobs retaining another 78 MB of engine_data.
• The largest job stores emergency_plan (764 KB) and apply_plan (617 KB), duplicating candidate inventory.

The human-readable log message already contains the useful summary. Persisting full candidate plans on an hourly recurring task amplifies both SQL storage and Markdown Database Integration full-table snapshots.

Source

• inc/Tasks/WorkspaceDiskEmergencyCleanupTask.php:129-140 logs report => $result and completes the job with $result.
• inc/Workspace/WorkspaceHygieneReport.php:363-388 returns both the full emergency_plan and overlapping apply_plan.

Expected

Recurring job logs and terminal job output should retain a bounded summary: trigger reasons, counts, measured recovery totals, action-required state/reasons, batch IDs, and capacity before/after. Full candidate rows should remain available only in explicit command/run evidence, not duplicated into every recurring log and job row.

Add deterministic coverage bounding serialized log context and terminal result size with a large candidate fixture.