enhancement: dewey_store_compiled should validate sources param maps to existing learnings

[jflowers]

Summary

dewey_store_compiled accepts a sources parameter (array of learning identities) but does not validate that the identities exist in the store. This makes it easy to pass incorrect source references that break provenance tracking.

Context

During a manual synthesis session (compiling 131 learnings across 6 repos into thematic articles), some compiled articles were stored with sources: ["ci-1"] when they should have referenced multiple learning identities. The tool accepted the input without warning.

Observed Behavior

dewey_store_compiled(
  tag="blast-radius-scope-audit",
  content="...",
  sources=["ci-1"]  // Should have been multiple identities
)
→ Stored successfully with sources: ["ci-1"]

SQLite confirms incorrect provenance:

SELECT name, json_extract(properties, '$.sources') FROM pages
WHERE name = 'compiled/blast-radius-scope-audit';
-- Returns: ["ci-1"]  (should be ~20 learning identities)

In contrast, articles stored with correct sources from dewey_compile output had proper provenance:

-- compiled/sandbox has 10 correct source identities
-- compiled/gateway has 4 correct source identities

Enhancement Request

1. Validate sources: Warn (or error) if a source identity does not match an existing learning page in the store
2. Auto-populate sources: When dewey_compile produces synthesis prompts, the compiled article could auto-link to the cluster's learning identities if the agent does not override them

Impact

• Incorrect provenance makes it impossible to trace a compiled article back to its source learnings
• dewey compile (full rebuild) cannot accurately determine which learnings have been compiled