Warden skips the on-call process

[ecv]

Summary

Warden, the production patrol skill, lives only in the infra repo and records what it finds in a monthly infra issue that the on-call rotation never reads.

Engineering runs on-call and incidents from its own repo, with a weekly on-call log, an incident issue template with a UTC timeline, and a label for alerts nobody tracks yet. Warden follows none of it, so a patrol's findings stay invisible to the next engineer on shift.

One pass moves warden into the plugin and lines it up with those practices.

Acceptance criteria

• A session in any Datum repo runs warden from the plugin, the infra copy is gone, the monthly Alerts Seen issue is closed out with no successor, and the infra runbooks and alerting standards that point at it point at the on-call log instead
• Warden reads recent on-call log comments and open incident issues before its first pass, then keeps one shift comment on the current week's log, edited in place, covering notable events, issues and PRs touched, and handoff
• An alert with no tracking issue gets an engineering issue with the monitoring label after a duplicate check, and rule hygiene notes go to the rule owner's repo instead of the shift comment
• A suspected incident produces a draft from the incident template with a UTC timeline, and warden stops for a person to declare it

The infra side of this lands as a companion infra PR in the same pass.

Related to https://github.com/datum-cloud/engineering/blob/main/docs/oncall.md
Related to https://github.com/datum-cloud/engineering/blob/main/docs/incidents.md

[ecv]

One thing to add, and I would put it alongside the existing criteria rather than inside one of them.

A patrol should read the silence list, and it should create silences.

Reading them first, because a patrol that does not is reporting a cleaner picture than reality. I spent much of today cataloguing production alerts and only later found that two of them, on the ClickHouse retention delivery unit and its migration job, had been deliberately silenced on 12 September with a seven day expiry. Everything I said about that part of the list was wrong until I read the silence. A teammate nearly filed a missing-alert issue for the same reason, against an alert that fires reliably and is simply quiet on purpose.

Creating them, because silencing a known thing is the on-call operator's job and nothing in the patrol does it today. When a patrol finds an alert that is tracked, understood, and not actionable by whoever is on shift, leaving it firing costs attention every day until someone else rediscovers it. Silencing it narrowly with an expiry converts it from noise into a dated reminder, which is exactly what the 12 September silences did.

Three things a patrol wants from the silence list beyond the count.

An alert that is firing and silenced is not the same as one that is firing, and a shift comment that does not separate them misleads the next reader.

A silence expiring inside the next shift is a scheduled re-notification, and the person taking that shift should know it is coming rather than meet it cold.

A silence that outlives the repair it was covering stops protecting anything and starts hiding the next fault in the same place, including a repair that only half worked. That one argues for clearing a silence when its issue closes, rather than letting it run to expiry.