Repeated --at conditions silently use the last value and make screening order-dependent

[emircbngl]

Summary

Repeating the same --at condition in candidate screen silently overwrites the earlier value. As a result, reversing two otherwise identical command-line arguments changes the screening verdict.

Reproduced on public main at 5100ab00cb8b2aa5d43682ab0e9b871bee8f7ac1.

Minimal candidate

All values below are synthetic and exist only to reproduce the CLI behaviour:

[SYNTH-R]

[SYNTH-R.properties.mu_n]
value = 2000.0
unit = "cm^2/Vs"
basis = "computed"
valid_range = { bias_v = [0.0, 0.5] }

Reproduction

Inside-range value followed by outside-range value:

tarhan --format json --quiet candidate screen \
  --from candidates.toml \
  --at bias_v=0.3 --at bias_v=0.9 \
  --require 'mu_n>=1000'

Observed (exit 0):

[
  {
    "identifier": "SYNTH-R",
    "verdict": "undecided",
    "why": "mu_n is stated valid for bias_v in [0, 0.5] but the run uses 0.9"
  }
]

Reverse only the two --at arguments:

tarhan --format json --quiet candidate screen \
  --from candidates.toml \
  --at bias_v=0.9 --at bias_v=0.3 \
  --require 'mu_n>=1000'

Observed (exit 0):

[
  {
    "identifier": "SYNTH-R",
    "verdict": "pass",
    "why": ""
  }
]

Cause

_candidate_screen() parses repeated --at flags into a dictionary without checking whether the condition was already supplied:

conditions[name] = value

The last occurrence wins silently.

Expected behaviour

Reject a repeated condition as invalid input (EXIT_INPUT, exit 2) and name the duplicate. This matches the existing handling of repeated --vary axes, which refuses to silently discard the first list.

Why this matters

The command currently produces a valid-looking success response for contradictory operating-condition input, while the verdict depends only on argument order. A caller cannot tell from stdout or the exit status that one supplied value was discarded.

Regression coverage

Add a CLI test that supplies bias_v twice, asserts exit 2, and checks that stderr identifies the repeated condition. The full suite currently passes (747 passed, 5 skipped, 4 xfailed), so this case is not covered.

[emircbngl]

Fixed in 04df808.

A repeated --at now exits 2 and names both values:

error: --at bias_v: given twice (0.3 and 0.9); the second would silently
replace the first and the verdict would depend on argument order

Both argument orders are refused, and a single condition still screens
normally (pass inside the range, undecided outside).

Reproduced exactly as filed before fixing. The regression test is
parametrised over both orders and asserts exit 2 plus both values in stderr;
a companion test asserts the guard rejects the duplicate rather than the
feature.

Worth recording why this one went first: --vary has refused a repeated axis
since it was written, so this was the fifth time in the current review cycle
that a guard existed on one of two sibling paths and not the other.

Note on the issue text — it cites 747 passed, 5 skipped, 4 xfailed; the
suite is at 773 passed / 4 xfailed / 0 skipped as of this commit. The
conclusion ("this case is not covered") was correct either way.

Push CI 7/7 and the cross-oracle job are green on this exact SHA.