feat(BA-6852): record Agent kernel transitions into scheduling history

[jopemachine]

Resolves #12785 (BA-6852)

Summary

Nothing wrote kernel_scheduling_history until now — KernelSchedulingHistoryCreatorSpec had no caller — so the kernel scheduling-history APIs (#12870/#12989/#12866) always returned empty lists. This implements the Manager-side recording/apply contract of BEP-1061 §3e, plus the unified event type from §3d that it consumes.

Piece	Change
Event (§3d)	KernelStatusTransitionAnycastEvent(kernel_id, from_status, to_status, reason, result, error_code, message) — no phase/step payload; from/to are sokovan KernelStatus values
Apply (§3e-2)	Atomic UPDATE … WHERE status = from in the scheduler repository, so a duplicate/stale transition matches nothing and is rejected idempotently; a FAILED report leaves the status untouched
Record (§3e-1)	History row written in the same transaction, mapping the transition onto phase/from_status/to_status/result/error_code/message; a redelivered identical record merges by incrementing attempts (at-least-once transport / sweep re-emission)
Follow-up	Applied transitions request the same ScheduleType marks as the granular handlers (e.g. CHECK_PULLING_PROGRESS after PULLING)
Guard	Targets outside the Agent-reportable phase set (PREPARING…TERMINATED) are ignored — CANCELLED/reschedule stays with sokovan session scheduling, per the BEP

phase derives from the Agent execution stage owning the target status (prepare / create / terminate, per the BEP handler table). TERMINATED transitions also free resource allocations, mirroring the existing terminated path.

Boundary

The Agent-side egress that emits this event is BA-6851 (not started); until it lands, the granular anycast events remain the live path and this handler consumes only what is published to the unified event. Migrating granular consumers is BA-6853.

Note: BA-6852 is assigned to @HyeockJinKim — this PR was made on jopemachine's direction to unblock the kernel history feature line; happy to hand over or adjust to your planned shape.

Test plan

• Unit — coordinator handler (13 cases): full domain of the 7 Agent-reportable target phases with their follow-up schedule marks, FAILED report without follow-up, stale rejection, unknown/non-reportable statuses ignored
• Repository (real DB, 6 cases): apply+record atomically; stale from rejected without history; redelivered applied transition rejected; FAILED records without status change; repeated FAILED merges to one row with attempts=2; non-reportable target ignored
• Live end-to-end: published the event onto the Redis events stream against a running manager — status applied (PULLING → PREPARED), history row recorded and visible to the kernel owner through scopedKernelSchedulingHistories, redelivered copy rejected (no duplicate), repeated failure reports merged (attempts=2)
• ruff check / ruff format clean

🤖 Generated with Claude Code

[jopemachine]

This work should be done after the agent refactoring.