Surface rejected unit operations / conflicts for observability

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.}