Files to Modify

• pkg/workflow/compiler_custom_jobs.go — detect a new optional memory: or restore-memory: field on custom job configs, and inject the corresponding restore steps before the user steps:
• pkg/workflow/cache.go — refactor/extract restore-only variants of generateCacheMemorySteps and generateRepoMemorySteps that do not emit write-back steps, for reuse in custom jobs and pre-activation
• Schema/docs — update the custom jobs schema if applicable
• Tests — add a test verifying that a custom job with memory: cache-memory gets the restore step injected

Approach

1. Design the frontmatter shape. A minimal option: custom jobs support a restore-memory: true (or a list of store names) field that opts in to memory restore injection. Alternatively, auto-inject when memory is configured and the job does not explicitly opt out.
2. In buildCustomJob (in compiler_custom_jobs.go), check for the memory-restore opt-in and prepend memory restore steps before the job's user steps:.
3. Extract a read-only restore step generator from generateCacheMemorySteps / generateRepoMemorySteps (these currently also emit git integrity setup steps that are agent-specific). The extracted version should only emit the actions/cache restore step and directory creation.
4. For comment-memory, emit the "Prepare comment memory files" step before user steps (token must be available — ensure the custom job has github-token access).
5. Add a compiler validation error if a custom job tries to write to memory (guard against misuse).

Notes

• Memory restore in custom jobs is read-only — write-back/commit steps must not be injected. Only the agent job writes back to memory.
• Related to issue Allow frontmatter to augment the needs list of any compiler-generated job #43918 (needs-wiring for compiler-generated jobs): if a restore-memory job is introduced as a shared job in the future, custom jobs could needs: it instead of each injecting their own restore steps.