Validate duplicate param names and input/global collisions with clear errors

[YogeshPraj]

Summary

Cleans up three cryptic "An item with the same key has already been added. Key: …" failures users hit when they accidentally introduce a name collision. Surfaced while triaging stale PR #402 — the underlying concerns it identified are real bugs even though that PR's proposed approach wasn't a fit.

The three cases

Case	When	Was	Now
Two GlobalParams in the same workflow with the same Name	Detected at AddWorkflow if eagerly used; otherwise at execution	Dictionary.ToDictionary throws "An item with the same key has already been added. Key: dup"	WorkflowsValidator throws RuleValidationException("Duplicate GlobalParam name 'dup'. GlobalParam names must be unique within a workflow.")
Two LocalParams on the same rule with the same Name	Same	Same cryptic error	RuleValidator throws RuleValidationException("Duplicate LocalParam name 'dup'. …")
Caller passes RuleParameter("foo", …) against a workflow with GlobalParam("foo", …)	At execution	Same cryptic error from result-tree construction	RulesEngine.AppendGlobals throws RuleException("GlobalParam name 'foo' collides with an input RuleParameter of the same name. Rename either the global or the input to disambiguate.") — flowed through the existing per-rule error-surfacing path so each rule's ExceptionMessage carries the explanation

Why this shape

• Compile-time validation for duplicate workflow definitions (cases 1 and 2) — these are author errors and should be caught when the workflow is loaded, before execution starts. Fits cleanly into the existing FluentValidation pipeline (WorkflowsValidator / RuleValidator).
• Run-time check for input/global collisions (case 3) — can only be detected when caller inputs are known. The check lives where the values are actually merged (AppendGlobals) and uses the same try/catch surfacing pattern other scoped-params errors already use in ExecuteAllRuleByWorkflow, so the behavior is consistent: each rule's ExceptionMessage explains the collision and IsSuccess = false.
• Messages live in HelperFunctions/Constants.cs alongside the existing validator strings — same convention.

Not in this PR

The other claims in PR #402 either don't reproduce on current main (Dynamic.Core new (…) syntax works without AllowNewToEvaluateAnyType) or are design debates rather than bugs (chained-rule result visibility, PostActions timing).

Test plan

• New test file DuplicateParamNameValidationTest.cs covering:
  • Duplicate GlobalParams → RuleValidationException with "duplicate" + offending name
  • Duplicate LocalParams → same
  • Caller input collides with global → per-rule ExceptionMessage contains "collide" + offending name; does NOT contain "same key has already been added"
  • Distinct names → still execute successfully (regression guard)
• All 174 unit tests pass on net6.0 / net8.0 / net9.0 / net10.0
• No public API surface change; behavior change is strictly more helpful errors on previously failing inputs