Resolve {{manual.NAME}} instead of leaving it as literal text

[Sev7eNup]

Problem

Every trigger seeds its event data into the run under the manual.* namespace, and {{manual.NAME}} is the form we tell authors to write — the README trigger table (for all six trigger types), docs/claude-reference.md, docs/workflow-designer-features.md, docs/workflow-styleguide.md, the docs site, the designer's variable picker, the ForEach config hint, and the AI prompt catalog (src/NodePilot.Ai/Prompts/activity-reference.md).

The resolver had no pattern for it. StepPattern cannot match it either — the tail after the dot is a user-chosen name, not one of its four fixed property tails — so:

1. the placeholder survived resolution untouched, and
2. it slipped past the T-7.1 unresolved-template check, which scans step patterns only.

The step then reported success having written the literal where the value belonged. Measured against a 1.2.6 lab install, in one run:

A={{manual.ziel}}      <- log activity, step Succeeded
B=WERT-DA              <- {{trg.param.ziel}}, same run, same value

The documented forEach pattern is hit directly: the UI tells the author to read the loop item as {{manual.<itemParameterName>}} in the child workflow, and the child never saw its item while reporting 3/3 succeeded.

Change

ManualPattern joins GlobalsPattern as a namespace pattern — a flat name lookup — applied in:

• the JSON-config pass (ResolveVariables), JSON-escaped like globals;
• the plain-string pass (ResolveStringValue), which also covers targetMachineId / credentialId;
• the PowerShell script path (PowerShellActivitySupport), so runScript and custom activities get the value with their usual context-aware quoting.

ResolveConfigForExecution now receives the run's input parameters, which it previously was never given.

A surviving {{manual.X}} is fatal with its own diagnostic — "Unknown trigger input(s) — this run carries no such value" — instead of being reported as a missing step, which would send the author looking for a node that was never meant to exist.

{{manual.output}} (a trigger input named like a step tail) overlaps both patterns over the same span; the script path's overlap dedupe now covers that the same way it already covered {{globals.output}}.

The MCP analyzer already treated manual.* as resolvable, so the engine was the odd one out — no analyzer change needed, and TemplateGrammarParityTests is unaffected (StepPattern is untouched).

Tests

tests/NodePilot.Engine.Tests/Execution/ManualParameterResolutionTests.cs — 4 end-to-end cases: resolves in config; agrees byte-for-byte with the {{trg.param.X}} spelling in the same run; an unknown input fails the step with the new diagnostic; the value reaches a runScript body.

Ran: dotnet test tests/NodePilot.Engine.Tests — 1836 passed.

Docs

CLAUDE.md (databus contract now names all three patterns and the new failure mode), docs/claude-reference.md, src/nodepilot-docs-ui/content/concepts/data-bus.md. The rest of the documentation already described this behaviour — it just wasn't true yet.