feat(correlation/attribution): substrate + idle handler (Phase 1)

v0 Phase 1 of ATTRIBUTION-ENGINE.md:

* AttributionStateRow SQLModel keyed on (identity_uuid, primitive)
  per ANTI direction — re-keying state rows when the v1 clusterer
  merges attackers is the migration debt v0 should not bake in.
  ATTRIBUTION-ENGINE.md updated with the deviation note.
* AttributionMixin: ensure_stub_identity_for_attacker, idempotent
  upsert_attribution_state, get_attribution_state[_for_identity],
  list_multi_actor_identities (the Phase 5 correlator's read).
* attribution.profile.{state_changed,multi_actor_suspected} bus
  topics + builder; wiki Service-Bus.md updated separately.
* attribution_worker.py: subscribes to attacker.observation.>,
  ensures stub identity per event, logs and continues. No merger,
  no state writes, no derived events — Phase 4 wires those.
* attribution/{aggregate.py,_thresholds.py} skeletons: Phase 2
  fills _aggregate_categorical, Phase 3 adds numeric+hash+dispatcher.

development/ATTRIBUTION-ENGINE.md

@@ -506,6 +506,17 @@ v0.
   Five states, no more (resist the urge to grow the enum).
 - **Subject of attribution in v0.** RESOLVED: `attacker_uuid`,
   not `identity_uuid`. v1 widens.
+  - **Deviation (Phase 1 implementation):** the engine actually keys
+    state rows on `identity_uuid` from day one, materialising a 1:1
+    stub `attacker_identities` row per Attacker on first observation.
+    Rationale: re-keying state rows when the v1 clusterer eventually
+    merges attackers is exactly the migration debt v0 should not
+    bake in. With identity-keyed state from the start, the v1
+    clusterer becomes a natural rollup operation (merge B's stub
+    identity into A's identity, recompute the union once on the
+    merge event) instead of a column-rename. No polymorphic
+    `subject_uuid` column. ANTI sign-off in conversation; saved as
+    memory `feedback_attribution_keys_identity`.
 
 ## Real open questions