Close out INFO-WP-0030; record second Emission Cadence declaration

INFO-WP-0030: register practice-pattern/explicit-unsafe-diagnostic-mode
(adapted from coordination-engine's OrwellLoggingDiagnostics candidate,
INFO-DEC-2026-003) at canon 0.13.0, close the assimilation, and notify
coordination-engine for COORDINATION-WP-0004-T02. Workplan finished.

INFO-WP-0029: record activity-core's source-owned declaration (T03/T04
done) with its expected-rate/calendar-schedule incompatibility as
demand/EmissionExpectedRateCalendar.md, and record audit-core's
structural-only observer evaluation of net-kingdom's declaration as a
steward note. No party has yet produced a real observer result against
traffic, so T05 and the workplan stay blocked on external action.

Updated artifact-count and practice-pattern-count assertions in
tests/test_cli.py and tests/test_service.py for the new artifact.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 317218@bnt-lap001
Assistant-Session: a8d6c0ab-c70f-4610-a288-576f44d747d4

demand/EmissionExpectedRateCalendar.md

@@ -0,0 +1,67 @@
+# Demand: Emission Cadence expected-rate calendar scope — non-uniform scheduled activity
+
+**Status:** proposed (change proposal to the Emission Cadence standard)
+**Date:** 2026-09-22
+**Source:** activity-core (source owner), domain `infotech`
+**Owner:** InfoTechCanon Emission Cadence standard (`standards/emission-cadence`)
+**Consumer evidence:** activity-core `docs/emission-cadence/activity-core-evidence.yaml` (commit `f20db47`)
+**Feedback:** `feedback/2026-09-22-activity-core-emission-cadence-declaration.md`
+**Workplan:** `INFO-WP-0029` (T04 records it; no design workplan exists yet)
+
+---
+
+## Demand signal
+
+A source-owned `expected-rate` entry can express only a fixed wall-clock
+window per event class. `activity-core`'s `sbom_catchup` activity runs on a
+weekday-only cron (`15 9 * * 1-5 Europe/Berlin`). Neither wall-clock window
+size is honest for that schedule:
+
+- A window sized to the daily period plus run slack (`PT26H`) is quiet on
+  Saturday and Sunday mornings for a correct reason — the activity is not
+  scheduled then — and `expected-rate` has no way to say so. Every weekend
+  raises a false finding.
+- A window wide enough to tolerate the weekend gap (`P4D`) can no longer
+  detect a genuine outage that starts and ends midweek, because it is now
+  wider than the real inter-run interval on weekdays.
+
+The consumer fell back to `heartbeat-or-reconciliation`/`reconciliation`
+against its own local activation count. That is correct and preserves
+validity, but it moves a genuinely rate-shaped activity out of the form built
+for rate expectations, and it depends on the source holding its own local
+count to compare against — an observer with no access to that local count
+cannot evaluate this stream at all.
+
+## Relationship to the other open gap
+
+`demand/EmissionActivityScope.md` (net-kingdom) describes a related but
+distinct problem: a source that can emit only while an attended process runs,
+where `expected_min: 0` is the only honest floor and silence carries no
+information outside a session. This demand is different: activity-core's
+source runs continuously and its schedule is fully known in advance — the
+problem is that the schedule is calendar-shaped, not that the source is
+intermittently absent. Both gaps point at the same root limitation (a single
+wall-clock window cannot represent every real scheduling shape) but call for
+different fixes, and a standard revision should look at both together before
+committing to one.
+
+## Options named by the consumer
+
+1. Let an `expected-rate` entry name a calendar — a cron expression and
+   timezone — so the evaluation window counts scheduled slots rather than
+   wall-clock time. A finding fires on a missed scheduled slot, not on an
+   off-calendar quiet period.
+
+## Constraints on a disposition
+
+- A new field changes the wire schema (`0.1`). Under the `0.x` rules that is
+  allowed with migration guidance. Existing declarations stay valid only if
+  the field is additive and optional.
+- Declarations pinned before the change stay pinned to their digest. Stable
+  promotion needs declarations against one fixed reading of the contract, so
+  a schema change before stable resets which pin later evidence should use.
+- This demand is not accepted. Choosing a design (calendar-aware
+  `expected-rate`, a new form, or documenting the `reconciliation` fallback
+  as the intended answer for calendar-shaped schedules) is a canon-owner
+  decision, and should be made alongside a disposition on
+  `demand/EmissionActivityScope.md` rather than separately.