chore: 178 - Include manifest reference in contribution records when applicable

[Exohayvan]

Roadmap step

phase-1/step-178: Step 178 - Include manifest reference in contribution records when applicable

Objective

Complete the selected roadmap step using only the programmatically selected step details.

Selected step

# Step 178 - Include manifest reference in contribution records when applicable

## Source Checklist Item
- [ ] Include manifest reference in contribution records when applicable.

## Goal
Ensure every contribution record can point back to the manifest that governed the work when a manifest exists. This preserves attribution, creator node ID context, validation lineage, and reproducibility without inventing references for work that was not manifest-backed.

## Implementation Checklist
- [ ] Add an optional manifest reference field to the local contribution record shape.
- [ ] Store a stable manifest identifier, path, or content hash rather than copying the full manifest into each contribution record.
- [ ] Record the manifest reference only when the contribution was produced from, validated against, or derived from a known manifest.
- [ ] Preserve existing contribution attribution fields, including creator node ID, worker node ID if present, task identity, output identity, timestamps, lineage pointers, and validation receipt links.
- [ ] Ensure records without an applicable manifest remain valid and explicitly omit or null the manifest reference instead of using a fake placeholder.
- [ ] Keep the change local-first and file/API compatible with the current Phase 1 prototype scope.

## Required Tests Or Verification
- [ ] Create or update a local contribution record from manifest-backed work and verify the manifest reference is present.
- [ ] Create or update a local contribution record from non-manifest work and verify no fake manifest reference is added.
- [ ] Verify validation receipts and lineage references still resolve after the manifest reference is added.
- [ ] Verify existing contribution records remain readable or migrate safely without losing attribution data.

## Risks
- [ ] Contribution records may imply false provenance if manifest references are added automatically without proof.
- [ ] Full manifest duplication may create stale or conflicting provenance data.
- [ ] Schema changes may break existing local records if backward compatibility is not preserved.

## Done When
- [ ] Contribution records include a manifest reference when applicable.
- [ ] Non-manifest contributions remain valid without fabricated provenance.
- [ ] Attribution, validation receipts, lineage, and creator node ID context are preserved.

Changes

b03509c chore: complete phase-1 step-178
 src/aethermesh_core/ledger.py | 14 ++++++++++++++
 tests/test_ledger.py          | 31 ++++++++++++++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletion(-)

Validation

• PYTHONDONTWRITEBYTECODE=1 python3 scripts/full_test.py --mode fast --base origin/main --keep-going

Safety notes

• Roadmap selection was performed by the Python loop, not by the AI agent.
• No force push used.
• No hard reset used.
• Local automation paths are intentionally omitted.