fix(frontend): keep the last value on a duplicate tool-call parameter

[adubkov]

Problem and scope

Related Issue: #244

Scope note — broader than #244. #244 asks only about byte-identical
duplicates and states "Conflicting duplicates keep the current rejection
either way". This branch coalesces conflicting values too.

Captured agent sessions argue for that. Across the <tool_call> blocks in
those logs every observed repeat was conflicting, none identical
(6 conflicting / 0 identical), so an identical-only rule would have
recovered none of them. The shape was consistent: the model emitted a
parameter, continued with other parameters, then restated that same
parameter with a shortened rewording of the same intent, e.g.

<parameter=description>   (initial wording)
<parameter=subagent_type> ...
<parameter=description>   (shorter restatement of the same request)

Taking the last value adopts the model's own correction rather than an
arbitrary tie-break. Generations are from a private session and are
summarised structurally rather than quoted.

The lossy-replay tradeoff #244 raises still applies and is not addressed
here: returning markup verbatim preserves byte-exact history
reconstruction, whereas one structured argument replays as one
<parameter=…> block where the model emitted two. That is a cache
checkpoint against a dead agent turn, and the maintainer's call.

When a model repeats a <parameter=name> inside one <function=...> block,
parse_parameter returns DuplicateParameter. The decoder then restores the
entire tool-call region verbatim as assistant content.

To an OpenAI-compatible client this arrives as ordinary prose with
finish_reason: "stop" and no tool_calls, which is indistinguishable from
the model deciding to answer in text. The tool is never dispatched and nothing
surfaces the failure, so it presents as a hung session.

Reproduced against an Ornith-1.5-35B-A3B artifact (qwen3_6 chat template),
non-streaming and streaming alike:

finish_reason : stop
tool_calls    : None
content       : "<tool_call>\n<function=read_file>\n<parameter=path>\n..."

Frequency on one local deployment, from the operational log:

requests with a parsed tool call : 220
fell back to text                :  11
    5  malformed structure
    3  undeclared tool
    3  duplicate parameter

Change

• parse_parameter keeps the last occurrence of a repeated parameter
  rather than discarding the call, matching how the same repetition reads in
  JSON object syntax. A call that is otherwise structurally sound survives.
• ToolCallParseDiagnostics::duplicate_parameters_repaired counts the repair
  so it is observable rather than silent, and is emitted in the request log.
• The fallback warning now includes a truncated, newline-flattened snippet of
  the offending markup. The reason alone names the verdict but not the bytes
  that earned it, which leaves malformed structure undiagnosable once the
  request is gone.

parse, parse_function and parse_parameter lose const because they now
update the repair counter. consume and find_parameter_close stay const.

Tests

tests/test_tool_call_parser.cpp:

• Added test_duplicate_parameter_keeps_last_value, covering the structured
  result, the last-wins value, fallback_reason == None, and the repair count.
• Removed the now-contradictory duplicate-rejection assertion from
  test_strict_structure_and_active_tool_set; that test is otherwise
  unchanged. The remaining 18 test functions are untouched.

Built and run in a container against this branch:

g++ -std=c++23 -O0 -Iinclude -Isrc -Ithird_party \
    src/models/qwen3_5/frontend/tool_call_parser.cpp \
    tests/test_tool_call_parser.cpp -o parser_test && ./parser_test
ok

Confirmed red before the change (5 assertions failing) and green after.

The full CUDA build succeeds and compiles the two touched serve files:

[348/433] .../qwen3_5/frontend/tool_call_parser.cpp.o
[398/433] .../ninfer_serve.dir/operational_log.cpp.o
[412/433] .../ninfer_serve.dir/request_log.cpp.o

End-to-end against a running server on this branch, a request whose history
contains two <parameter=path> entries with different values:

finish_reason : tool_calls
tool_calls    : [{"function": {"arguments": "{\"path\":\"/etc/hostname\"}", ...}}]
content       : None

Not run: the project's full test suite per tests/README.md, and any
benchmark. This change is not on a numerical or performance path.

Not addressed

Output-limit / truncation fallback is tracked separately in #169 and is out of
scope here.

malformed structure (the largest bucket above) is untouched. It is produced
by unclosed markup — output that ends inside a <parameter=...>, <function=
or <tool_call> block, i.e. the model stopping mid-call. Auto-closing those
would hand the caller a structurally valid call carrying a truncated
parameter value, which for an argument like a command or a subagent prompt is
worse than not dispatching at all. A duplicate parameter is different: both
values are complete, so taking the last one loses nothing.