Unify human-node completion signalling behind an OutcomeSignaler service

Follow-up to #3610065.

Four code paths complete a human node by turning a submitted result into the process variables to signal: the inbox work item (WorkItemManager::complete), the pull operation form (UserOperationForm::submitForm), the direct outcome signal (OperationController::signal) and the interaction operation resume (OperationResumer::resume). Each repeats the same block: resolve the outcome and completer through OutcomeResult::fromConfig, resolve the node task type, fold in any variables it contributes through ResultVariablesInterface, then signal the token.

That duplicated assembly should live in one place, so the completion contract cannot drift between the push (inbox) and pull (operation) surfaces.

Proposed change: a small OutcomeSignaler service in orchestra core, holding the engine and the task type manager, with two methods:

• resolve(node, result, completerUid): assemble the OutcomeResult and fold in the task type ResultVariablesInterface extras.
• signal(token, node, result, completerUid): resolve, then signal the token.

OutcomeResult gains an immutable merge() so the outcome and completer variables keep winning on a key collision. The four callers collapse onto the service; WorkItemManager keeps its own task lock and fresh-token reload and uses resolve() for the assembly only.

No behavior change: the same variables are signalled. A new kernel test covers the assembly (plain task, comment task, key-collision precedence, unresolved type), and the existing completion suites continue to pass.