Reject duplicate limits, named tool arguments, and model context keys #38

Problem

Repeated entries in a limits block or named tool arguments silently replace earlier values. A workflow can therefore declare tool_calls <= 0 and still compile with a one-call budget if a second entry appears later.

Reproduced on main at f5db6e2 and installed guardstep@0.1.0-alpha.1.

Reproduction

Save as duplicates.guard and run guardstep check duplicates.guard, followed by guardstep compile duplicates.guard:

enum Failure { DENIED TIMEOUT ERROR INVALID DURATION COST }
record Input { text: String }
tool echo(text: String) -> Input

workflow Example(input: Input) -> Input fails Failure {
  capabilities { echo else DENIED }
  limits {
    tool_calls <= 0
    tool_calls <= 1
    model_calls <= 0
    duration <= 1s else DURATION
    cost <= 0 USD else COST
  }
  result = call echo(text: input.text, text: "overridden")
    on timeout => fail TIMEOUT
    on error => fail ERROR
    on invalid => fail INVALID
  return result
}

Checking exits 0. The IR contains tool_calls: 1 and only the literal "overridden" for text; the previous values are lost.

Expected behavior

Reject repeated keys with source-located duplicate-entry diagnostics, consistent with existing duplicate record fields, parameters, and capabilities.

Starting point

packages/guardstep/src/compiler/parser.ts: parseLimits and parseToolStep overwrite scalar variables/object entries while parsing. Model context entries use the same unchecked assignment pattern in parseModelStep.

Acceptance criteria

• Reject duplicates for all four limit names, named tool arguments, and model context keys before overwriting them.
• Test each form independently so one diagnostic cannot hide a second defect.
• Identify the repeated key and its source location.
• Keep unique entries and their existing ordering behavior unchanged.
• Add compiler/CLI regression coverage without executing host code or model providers.