PR #60718: fix: resolve startedAt timestamp inversion in task registry

• Repository: openclaw/openclaw
• Author: akramcodez
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60718

Description (problem / solution / changelog)

Summary

• Problem: Task metadata records show startedAt < createdAt because callers assign startedAt = Date.now() prematurely before the registry inserts the record.
• Why it matters: This logic invalidates chronological order, breaking observability/audit tools that expect strict startedAt >= createdAt invariants.
• What changed: Moved startedAt default generation directly into task-registry.ts at the exact point of execution insertion. Clamped explicitly passed startedAt values (like from cron) safely via Math.max(createdAt, startedAt).
• What did NOT change: createdAt assignment logic remained completely immutable.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #60632
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Race conditions springing from execution handlers manually injecting Date.now() into startedAt fractions of a millisecond prior to the database/registry generating createdAt.
• Missing detection / guardrail: No system-level validation checked if startedAt >= createdAt before assignment.
• Contributing context (if known): Cron jobs must calculate their theoretical timing prior to their insertion tick.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cron/service/cron-timestamp.test.ts
• Scenario the test should lock in: Mocking Date.now() moving forward between payload generation and registry insertion, ensuring bounds are clamped correctly.
• Why this is the smallest reliable guardrail: Simulates exactly the timeline delay identified in local auditing.
• Existing test that already covers this (if any): None.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

None.

Diagram (if applicable)

Before:
[Runner eval: T] -> [Registry Insert: T+2] -> [Result: startedAt=T, createdAt=T+2 (Invalid)]

After:
[Runner eval: T] -> [Registry Insert: T+2] -> [Result: startedAt=T+2, createdAt=T+2 (Valid)]

## Changed files

- `src/acp/control-plane/manager.core.ts` (modified, +2/-3)
- `src/agents/acp-spawn.ts` (modified, +0/-2)
- `src/agents/subagent-registry-run-manager.ts` (modified, +0/-1)
- `src/tasks/cron-timestamp.test.ts` (added, +67/-0)
- `src/tasks/task-registry.ts` (modified, +24/-6)