chore: 145 - Log result reporting

[Exohayvan]

Roadmap step

phase-1/step-145: Step 145 - Log result reporting

Objective

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

Selected step

# Step 145 - Log result reporting

## Source Checklist Item
- [ ] Log result reporting.

## Goal
Create a local-first audit log entry for every result reporting action so the prototype can prove when a node reported work output, what was reported, which manifest and validation receipt it referenced, and how creator node ID, lineage, and contribution attribution were preserved. This step only covers logging the reporting event; it does not add dashboards, rewards, networking, or token logic.

## Implementation Checklist
- [ ] Define a result-report audit event shape with timestamp, creator node ID, reporting node ID, work ID, manifest ID, validation receipt ID, lineage reference, contribution attribution reference, result status, and deterministic event ID.
- [ ] Write result-report events to the local audit log whenever a result is accepted for reporting.
- [ ] Ensure log entries reference existing manifests and validation receipts instead of copying or mutating them.
- [ ] Include enough context to reconstruct the local reporting path without exposing unrelated private data.
- [ ] Make duplicate reporting attempts idempotent by reusing or clearly linking the same deterministic event identity.
- [ ] Keep the log format simple, append-only, and readable by local validation tooling.

## Required Tests Or Verification
- [ ] Run a local result reporting flow and confirm an audit entry is appended.
- [ ] Verify the entry includes creator node ID, manifest ID, validation receipt ID, lineage, and contribution attribution references.
- [ ] Verify a missing manifest or validation receipt blocks logging as a valid reported result.
- [ ] Verify duplicate reporting does not create misleading unrelated audit history.

## Risks
- [ ] Audit entries may become untrustworthy if they omit validation or lineage references.
- [ ] Overly large entries may duplicate manifests instead of preserving clean references.
- [ ] Non-idempotent logging may make contribution attribution ambiguous.

## Done When
- [ ] Every local result reporting action produces a validation-linked audit entry.
- [ ] Invalid or incomplete reporting attempts are rejected or logged separately as failures.
- [ ] The audit log can support later review of who reported what, against which manifest, receipt, lineage, and attribution record.

Changes

1ded0a0 chore: complete phase-1 step-145
 src/aethermesh_core/local_audit_event.py | 39 ++++++++++++++++++
 src/aethermesh_core/runtime_service.py   | 71 ++++++++++++++++++++++++++++++++
 tests/test_local_audit_event.py          |  2 +-
 tests/test_runtime_service_api_cli.py    | 62 ++++++++++++++++++++++++++++
 4 files changed, 173 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.