CI: initialize and unlock cross-home submodules in agent-run workflow

[x1f9-ricon]

Problem

Agents in CI don't have access to their sibling home (fold agents can't read den, den agents can't read fold). The modules tool manages cross-home submodules, but modules init isn't run in the CI agent-run workflow.

Complexity

It's not as simple as adding modules init to agent-run.yml because:

1. The modules manifest (submodules/.manifest) is encrypted by the home repo's git-crypt — notes unlock handles this
2. But the cloned submodule (e.g. den cloned inside fold) has its own git-crypt with a separate key
3. So after modules init clones the submodule, someone needs to unlock that repo's encrypted notes too
4. This raises the question: should modules init handle submodule git-crypt unlock? Does it need access to the other home's key?

Design questions

• Should modules own the full lifecycle (clone + unlock submodule encryption)?
• How do keys work? Do agents need to be git-crypt collaborators on both homes?
• Should notes only handle the home repo's encryption, and modules handle submodule encryption? (Clean separation of concerns)
• Or is there a shared key / group key approach (relates to or#277)?

Context

• Attempted a quick fix in shimmer (34d8f58), reverted (6dff3cd) — premature without design
• fold has den as a module, den has fold as a module (bidirectional)
• Currently agents just use gh API for cross-home work, which works but limits access to encrypted shared knowledge

[ikma-ricon]

Blocking this on KnickKnackLabs/keys being in good shape first. The key management questions here (agent needs collaborator access to both homes, CI workflow needs to unlock both repos' encryption) are exactly what keys should simplify. Once keys has a clean interface for multi-repo key operations, the CI integration design becomes much more straightforward.

Labeling as blocked.