fix portable memory ownership across redeploys

[mostlydev]

Summary

Portable memory still does not meet the out-of-the-box ownership contract for managed pods.

The v0.8.13 hotfix stops claw up from aborting when host-side permission normalization hits EPERM, but that only masks the ownership mismatch. Managed services intentionally run under varying container UIDs, so a previous generation can leave .claw-memory/<service>/memory/** owned by a container UID that the host user cannot later chmod. On the next claw up, Clawdapus may continue with a warning while leaving files or directories effectively unwritable for the next runtime.

Why this matters

Clawdapus defaults should not require operators to manually repair ownership after routine claw up / claw down cycles. If pods are managed out of the box, the portable memory surface must remain writable across redeploys without manual intervention.

Constraints

• Managed services already support non-root runtime users; we cannot assume containers run as the invoking host UID.
• Portable memory is durable state under .claw-memory/ and is pre-migrated before compose apply.
• Current host-side normalization cannot reliably fix ownership once a different UID owns the tree.
• Any fix should preserve cross-driver portability and not regress the existing non-root driver behavior.

Proposed scope

1. Add a real normalization path that can repair modes/ownership for the portable memory tree even when the host user cannot chmod it directly.
2. Add stable per-service runtime ownership defaults so managed services stop drifting to arbitrary writer identities across redeploys.
3. Add regression coverage for the real failure mode: one generation writes memory under one UID with restrictive permissions, a later claw up under a different effective writer still succeeds without manual repair.

Open questions

• Should normalization happen via a short-lived Docker helper container operating on the bind mount, via docker compose run/exec, or via a stricter fixed UID/GID policy across drivers?
• Which drivers can safely adopt explicit service user: defaults without breaking upstream home-directory assumptions?
• Do we need a one-time migration path for existing pods whose portable memory trees are already owned by legacy UIDs?