Follow-up from self-review on #27149.

The unit event log added in #27149 records only successful graph mutations. During review we considered also recording rejected operations (e.g. dependency cycles/conflicts, same-status updates, updates to unregistered units) so operators can see when units conflict.

We deferred this deliberately:

• The event log's core invariant is "an ordered sequence of successful state mutations" (readiness-interval reconstruction depends on it). Injecting non-mutating "rejected" entries breaks that replayability.
• Most rejections (same-status, duplicate registration, unregistered unit) are benign/idempotent, not conflicts, so a blanket "record failures" would mostly add noise.
• Only genuine conflicts (cycle detection on AddDependency) are operationally interesting, and surfacing them well likely means a separate diagnostics/warnings channel plus a reason field, rather than polluting the ordered event log.

Proposed scope

• Decide on a surface for conflict/diagnostic signals separate from the replayable event log.
• Record cycle/conflict rejections with a reason.
• Expose via the agent socket (status/timeline) and CLI.

Related: the maxEvents cap in agent/unit/manager.go could grow into a ring buffer if event volume ever becomes large (also noted in #27149 self-review).

_{Filed by Coder Agents on behalf of @SasSwart.}