Federate LI per-proposal execution outcomes back to the originating peer

[atomantic]

Discovered by codex during review of #2765 (P1).

Problem

CoS tasks are federated (#1712/#1714), so an LI hand-off task filed on peer A can be claimed and executed on peer B. #2765 records the execution outcome (recordProposalExecution) into the local data/cos/li-outcomes collection of whichever peer ran the agent. That collection is NOT federated, and the originating peer (A — where the proposal was filed and where LI runs for that app) never derives an execution outcome from the terminal synced task. So computeProposalExecutionAwareness on A never reflects a proposal B executed, and the per-domain learning signal is incomplete on multi-peer installs.

Single-install and same-peer-files-and-executes cases (the common ones) are correct today; this is strictly the cross-peer gap.

Options

1. Federate the li-outcomes collection — add it to the cross-install sync surface with the full guard checklist (schemaVersions, peerSync NON_RECORD/OUT_OF_BAND, dataSync, manifest, LWW merge, promote). Heaviest but most general; then any peer's execution write converges to all peers.
2. Route the result back via the federated task — stamp the execution outcome into the hand-off task's federated metadata on completion, and have the originating peer derive recordProposalExecution from the terminal synced task (it already syncs task state). Lighter, keeps li-outcomes local, but needs a "task carries its execution verdict" convention + a consumer on the filing peer.

Prefer (2) if the task-federation payload can carry a small verdict; fall back to (1) if per-proposal outcomes need to be queryable independent of task retention.

Affected files

• server/services/taskLearning/metrics.js (recordTaskCompletion post-lock hook) — where the local write happens today
• server/services/layeredIntelligenceOutcomes.js (recordProposalExecution)
• Federation surface: server/lib/schemaVersions.js, server/services/sharing/*, server/services/dataSync* (option 1), or the CoS task federation merge (cosTaskMerge.js, option 2)

Acceptance

• A proposal filed on peer A and executed on peer B is reflected in A's computeProposalExecutionAwareness after a sync, verified by a federation test.
• No cross-peer schema-version corruption (newer peer can't break an older one).

[atomantic]

Triage decision — making this actionable. Chosen approach: option 2 (route the verdict via the federated task). Stamp the execution outcome into the hand-off task's federated metadata on completion and have the originating peer derive recordProposalExecution from the terminal synced task, keeping li-outcomes local. Lighter than federating the whole collection and sufficient for the per-domain learning signal. Fall back to option 1 only if per-proposal outcomes later need to be queryable independent of task retention. Removing future, labeling plan.