fix: defer memory file scaffold when Abilities API unavailable at activation

[chubes4]

Summary

Fixes #988 — USER.md (and agent-layer memory files) were not scaffolded during plugin activation because the Abilities API isn't available at that point.

Root Cause

During plugin activation, WordPress fires init before including the plugin via plugin_sandbox_scrape(). This means our add_action('init', ...) callback that registers abilities never runs in the activation request. When datamachine_ensure_default_memory_files() calls ScaffoldAbilities::get_ability(), it returns null and the function silently bails.

This is expected WordPress behavior, not a core bug. The Abilities API explicitly blocks initialization before init and is designed for the normal request lifecycle.

Fix

Three small, focused changes:

1. datamachine_ensure_default_memory_files() now returns bool — true if scaffold ran, false if abilities were unavailable. Backward-compatible: existing callers that ignore the return value are unaffected.

2. datamachine_activate_for_site() sets a transient on failure — when the scaffold bails during activation, set_transient('datamachine_needs_scaffold', 1, HOUR_IN_SECONDS) flags that work is pending.

3. Deferred init hook at priority 20 picks up the transient on the first normal request (after abilities register at priority 10), runs the scaffold, and deletes the transient.

Why this approach

• Respects the Abilities API design — no bypassing the registry or duplicating filesystem logic
• One-shot: the transient fires once then self-cleans
• Auto-expires (1 hour) so it can't get stuck
• Also covers the datamachine_maybe_run_migrations() edge case (runs at init priority 5, before abilities register at 10)