bregctl dev delivers change-request events only to its own receiver

Found while writing the public tutorial `Review BReg changes in Casework` (0.30.0 plus the `caseworkctl dev --source-project` work that ships with it).

## Use Case

A reader runs `bregctl dev` and `caseworkctl dev --source-project` side by side. The Casework dev session should learn about a submitted change request the moment the registry emits its event, the same way a deployed Casework runtime does through the registry's webhook destination.

## What we hit

`bregctl dev` writes `eventDestinations` for exactly one receiver: its own retained webhook port, computed by `event_destinations(&compiled, port)` in `crates/registry-bregctl/src/dev/config.rs`. A second local subscriber cannot be registered, so the Casework dev session only learns about new work through reconciliation (the `caseworkctl dev` binding uses a short interval for that reason, see the `reconciliationIntervalMilliseconds` binding setting).

## Proposed Behavior

Let a `bregctl dev` session deliver events to an additional local subscriber: either a documented `--event-subscriber ` style option on `bregctl dev`, or a local registration that `caseworkctl dev --source-project` performs through the public `bregctl` CLI (never a crate dependency, the same rule `caseworkctl source add` follows). The registry's own receiver keeps working.

## Boundaries

Loopback only, HMAC key handled as a file secret the way the existing receiver does, and the dev session must still refuse non-loopback destinations. Related: #936 proposes webhook and PostGIS modes for `bregctl dev`.

Triage: later, not needed for the tutorial (reconciliation covers it).

Beginne in crates/registry-bregctl/src/dev/config.rs bei event_destinations(&compiled, port), und lies anschließend das reconciliationIntervalMilliseconds-Binding, das von caseworkctl dev verwendet wird. Verfolge, wie der bestehende beibehaltene Receiver seine Loopback-Prüfung und sein HMAC-Dateisecret handhabt. Fertig ist die Arbeit, wenn eine bregctl dev-Sitzung Ereignisse an einen zusätzlichen Loopback-Subscriber liefern kann, während sie ihren eigenen Receiver beibehält und Ziele außerhalb von Loopback ablehnt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.