feat(orchestrator): gate inclusion policy on NodeInterviewComplete (part of #203)

[Assar63]

Turns "identity is now known" (from the interview, #224) into "device-default policy actually applies" — the original motivation for #203.

Problem

InclusionOrchestrator applied effectivePolicy on NodeIncluded, but the (manufacturerId, productTypeId, productId) triple that PolicyRegister keys device-level defaults on isn't known until the interview gathers it. So device defaults silently never matched at inclusion — only per-node overrides did.

Change

Split the orchestrator across the two events:

• onNodeIncluded — keeps the lifeline (the node needs the controller in group 1 early, before it reports) and caches the supported-CC set.
• onNodeInterviewComplete — runs the policy step: effectivePolicy (now with device identity known → device defaults match) merged with the per-node override, applied gated on the cached supported CCs, then InclusionPolicyApplied + InclusionComplete.

Post-inclusion order is now explicit: SecurityBootstrap → Interview → Policy.

Tests

The 5 existing InclusionOrchestrator tests now publish NodeInterviewComplete after NodeIncluded; the emitted command/event sequence is unchanged (bus dispatch is synchronous, so the policy events still land right after the lifeline). 474/474 ctest green on both gnu and llvm; clang-format + clang-tidy clean.

Note / trade-off

Policy now waits for the interview to complete. A node that never answers the interview Gets won't get auto-policy (it's barely functional anyway) — the issue's accepted design. The interview runs for every included node (#224), so in the common case policy applies as before, just after identity is known.

Remaining #203

• persist the gathered identity into node-registry (console / Node info window #45 display);
• sleeping-node interview via PendingQueue.

Part of #203.

🤖 Generated with Claude Code