feat: thread Qhorus trigger context (channelId + correlationId) from CaseFile-update API through to ProvisionContext

[mdproctor]

Context

engine#229 added triggerChannelId and triggerCorrelationId to ProvisionContext to enable Claudony's WorkerProvisioner to link a CaseLedgerEntry back to the Qhorus COMMAND that triggered provisioning (completing the W3C PROV-DM causal chain).

However, the engine call site in CaseContextChangedEventHandler.tryProvision() currently passes null for both fields — the engine has no mechanism to receive trigger context from outside, so it genuinely cannot populate them.

Problem

The async chain that leads to provisioning is:

Qhorus COMMAND arrives at Claudony
  → Claudony updates engine CaseFile via API        ← trigger context lost here
  → Engine fires CaseContextChangedEvent            ← no trigger context carried
  → CaseContextChangedEventHandler.tryProvision()   ← creates ProvisionContext with null fields
  → ClaudonyWorkerProvisioner.provision(caps, ctx)  ← receives null, cannot correlate

Vert.x context does not survive crossing the engine's internal event bus, so Claudony cannot self-correlate using reactive context propagation alone.

Required changes

1. Engine API — the CaseFile-update endpoint (or equivalent entry point used by Claudony) must accept optional triggerChannelId and triggerCorrelationId fields
2. CaseContextChangedEvent — carry the trigger fields through from the API call
3. CaseContextChangedEventHandler.tryProvision() — read trigger fields from the event and populate ProvisionContext instead of passing null
4. Claudony (claudony#94) — pass the triggering COMMAND's channelId + correlationId when calling the engine API

Acceptance criteria

• ProvisionContext.triggerChannelId() and triggerCorrelationId() are non-null when provisioning is triggered by a Qhorus COMMAND
• Claudony's ClaudonyWorkerProvisioner can use them to look up the MessageLedgerEntry and set causedByEntryId on the CaseLedgerEntry
• Engine call sites that are NOT triggered by a Qhorus COMMAND (e.g. direct API provisioning) continue to pass null — nullable is correct for those paths

References

• engine#229 — added the fields to ProvisionContext (this issue threads them through)
• engine#230 — normative layer audit (broader context)
• claudony#94 — Claudony provisioner side that consumes triggerChannelId/triggerCorrelationId