chore: 143 - Log job execution start

[Exohayvan]

Roadmap step

phase-1/step-143: Step 143 - Log job execution start

Objective

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

Selected step

# Step 143 - Log job execution start

## Source Checklist Item
- [ ] Log job execution start.

## Goal
Add a local-first audit log entry whenever a job begins execution, so each work attempt has a durable start record before any processing, validation, or result writing occurs. The record must support later reconstruction of job lineage without implying distributed consensus, rewards, dashboards, or production security.

## Implementation Checklist
- [ ] Identify the local job execution boundary where a queued or requested job transitions into running.
- [ ] Emit an append-only audit event before job work begins.
- [ ] Include stable identifiers needed for traceability: job ID, creator node ID, executing node ID, manifest ID or manifest path, contribution attribution fields, parent lineage reference if present, and start timestamp.
- [ ] Include the job input or manifest hash rather than duplicating large payloads.
- [ ] Mark the event type clearly, such as `job.execution.started`.
- [ ] Ensure the log write is local, deterministic, and does not require network access.
- [ ] Ensure failure to write the start audit event blocks job execution or returns an explicit validation error.
- [ ] Avoid adding status dashboards, reward logic, tokenomics, peer claims, or later-phase replication.

## Required Tests Or Verification
- [ ] Run a local job and confirm exactly one start audit event is written before execution output.
- [ ] Verify the event preserves creator node ID, manifest reference, lineage reference, and attribution fields when provided.
- [ ] Verify a missing required identifier causes a clear validation failure.
- [ ] Verify repeated jobs produce separate start events without overwriting prior records.

## Risks
- [ ] Logging after execution begins could create unverifiable work with no start receipt.
- [ ] Missing lineage or attribution fields could weaken contribution tracking.
- [ ] Overly broad logging could leak full prompts, private payloads, or unnecessary data.
- [ ] Treating the log as distributed proof would overstate Phase 1 guarantees.

## Done When
- [ ] Every locally executed job has a validation-gated `job.execution.started` audit entry before work begins.
- [ ] The start event is append-only, locally inspectable, and sufficient to connect the job to its manifest, creator node, lineage, and contribution attribution.

Changes

4860e47 chore: complete phase-1 step-143
 src/aethermesh_core/local_audit_event.py |  41 ++++++++++
 src/aethermesh_core/runtime_service.py   |  86 ++++++++++++++++++--
 tests/test_local_audit_event.py          |  34 +++++++-
 tests/test_runtime_service_api_cli.py    | 131 +++++++++++++++++++++++++++++++
 4 files changed, 283 insertions(+), 9 deletions(-)

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.