feat: expose registered injectable memory files as a queryable list

[chubes4]

Summary

Add a generic read surface (CLI + backing ability) that returns the memory files registered for injection for a given agent, resolved to absolute on-disk paths plus metadata. This exposes — as a queryable list — the same "which registered files should inject?" answer that CoreMemoryFilesDirective already computes internally for DM's own AI calls.

Motivation

DM's MemoryFileRegistry is the single source of truth for which memory files exist, what layer they belong to, and which are marked for injection (injection_contexts, retrieval_policy => always). Today that knowledge is only consumed internally by CoreMemoryFilesDirective when building DM chat/pipeline AI calls. There is no way for any other consumer to ask DM "what memory files should this agent have in context?"

A consumer that assembles an agent's session context from outside a WordPress request needs exactly this list — but has no agnostic way to get it, so today such consumers maintain their own hand-written, parallel file list that silently drifts whenever a new memory file is registered in DM (e.g. WAKE.md from #2557 / PR #2567 registers fine but no external consumer can discover it).

CRITICAL: this must stay agnostic to how it is consumed

Non-goal / hard constraint: this command MUST NOT know about or reference any external runtime, session host, config-file format, or "instructions list" concept. It answers only a question about DM's OWN state: "which of my registered memory files are marked for injection, and where do they live on disk for this agent?"

• No opencode, kimaki, or any runtime/vendor name anywhere in the code, flags, docblocks, or output keys.
• No output shape tailored to a specific consumer's config format (no "instructions array" mode). Emit generic resolved paths + metadata; the consumer decides what to do with them.
• The grep test (grep -riE 'opencode|kimaki|discord|telegram|external.runtime') on the new code must come back clean.
• If implementing this tempts you to add a consumer-shaped flag (e.g. --for-<runtime>), that is the signal the boundary is being violated — keep DM emitting generic data and let the consumer format it.

This is the agnostic capability; the vendor-specific glue (turning this list into a particular runtime's session context) lives entirely in the consuming integration layer, NOT here. (Consumer side tracked separately in wp-coding-agents.)

Proposed surface

wp datamachine memory injectable-files --agent=<slug> --format=json

Returns, for the resolved agent, the registered files whose injection policy means "should be in agent context" (the same filtering CoreMemoryFilesDirective applies), each resolved to an absolute path via the existing layer resolution (shared → agent → user → network) + convention_path handling:

[
  { "filename": "SOUL.md",   "layer": "agent",   "path": "/.../agents/<slug>/SOUL.md" },
  { "filename": "MEMORY.md",  "layer": "agent",   "path": "/.../agents/<slug>/MEMORY.md" },
  { "filename": "WAKE.md",    "layer": "agent",   "path": "/.../agents/<slug>/WAKE.md" },
  { "filename": "USER.md",    "layer": "user",    "path": "/.../users/<id>/USER.md" },
  { "filename": "SITE.md",    "layer": "shared",  "path": "/.../shared/SITE.md" }
]

Implementation notes

• Reuse the existing resolution: MemoryFileRegistry for the registered set + injection policy, the same MemoryPolicyResolver/layer logic CoreMemoryFilesDirective uses, and AgentMemory/registry path resolution (including convention_path) for absolute paths.
• Back the CLI with an ability so REST/MCP can call it too (Abilities API pattern — logic lives in the ability, CLI is a thin wrapper).
• Only include files that actually resolve to an existing (or self-healing) path; skip files registered but not injectable.
• Respect agent scoping/permissions consistent with other datamachine memory subcommands.

Acceptance criteria

• wp datamachine memory injectable-files --agent=<slug> --format=json returns the agent's injectable memory files as absolute resolved paths + layer metadata.
• The set matches what CoreMemoryFilesDirective would inject for that agent (same registry + policy filtering) — including newly registered files like WAKE.md, with zero hand-maintenance.
• No external-runtime / vendor names anywhere in the new code (grep-clean).
• No consumer-format-specific output mode.

Constraints

• Conventional commits (feat:).
• Do NOT edit CHANGELOG.md; do NOT hand-bump versions.
• Layer purity is the whole point of this issue — see the "must stay agnostic" section above.