fix(abcip): report ALMD transitions with ConditionId = RawPath and a Kind (#641)

Found while verifying item 4 of #641. The host routes a native alarm transition
on an exact ConditionId == RawPath match (DriverHostActor.ForwardNativeAlarm),
but AbCipAlarmProjection emitted "{ref}#active" and no Kind, so every ALMD
raise/clear was dropped as "no alarm condition" — and even if routed, an
Unspecified kind projects no state change. It now reports the subscribed
reference (the RawPath) and Raise/Clear. A host test pins that a decorated id
is dropped.

FOCAS has the same id shape plus a device filter keyed by host address (a
RawPath subscription polls nothing); it needs a mapping decision and is
documented in docs/drivers/FOCAS.md rather than patched here.

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

docs/drivers/FOCAS.md

@@ -294,6 +294,13 @@ Every alarm transition fires `OnAlarmEvent` with:
 Cleared alarms fire a second event with `" (cleared)"` appended to the message
 so downstream consumers can ignore the clear if they only care about raises.
 
+> ⚠️ **Not routable to a v3 raw condition (found under Gitea #641).** The server routes a native transition
+> only when `ConditionId` equals an alarm-bearing raw tag's RawPath, and the host subscribes those RawPaths —
+> but this projection filters devices by **host address** (so a RawPath list matches no device and nothing is
+> polled) and emits `"{host}#{Type}:{AlarmNumber}"` with no `Kind`. FOCAS native alarms therefore reach no
+> Part 9 condition today. Fixing it needs a mapping decision (the CNC exposes one flat alarm list per device,
+> not one condition per tag), so it is tracked separately rather than patched.
+
 ## Handle recycling
 
 FANUC CNCs have a finite FWLIB handle pool (~5–10 concurrent connections) and