Bind named parameters by the name the statement declares

[RagingKore]

Builds on #351. That one needs to merge first. The first 13 files in this diff belong to it. This PR's own change is 8 files.

Closes #203.

TL;DR

This did not bind:

command.CommandText = "SELECT $PARM1::INT";
command.Parameters.Add(new DuckDBParameter("$PARM1", 42));

The statement declares the parameter as PARM1, without the marker, so a ParameterName of $PARM1 matched nothing. Other ADO.NET providers accept the prefix. Now this one does.

Fixing it exposed a second defect. This bound nothing at all and reported nothing:

command.CommandText = "SELECT $name::INT";
command.Parameters.Add(new DuckDBParameter("Name", 42));   // wrong case
command.ExecuteScalar();

The engine then failed with a message naming no parameter. It now throws InvalidOperationException: No value supplied for parameter 'name'. before execution.

The bug

foreach (var param in parameterCollection)
{
    var state = DuckDBBindParameterIndex(preparedStatement, out var index, param.ParameterName);
    if (state.IsSuccess())
    {
        BindParameter(preparedStatement, index, param);
    }
}

No else. A name the statement does not declare returns a failure the loop discards. Both cases above are that missing branch.

The loop also asks the wrong question. "Does the statement want this value?" has no sensible failure action, because unused values are legal. "Do I have a value for this parameter?" does.

The fix

The loop runs over the statement instead. It reads each declared name through a new duckdb_parameter_name binding, finds the value in the collection, and throws when none supplies it.

Matching makes two passes: an exact match over the whole collection first, then one that strips a leading $. Two passes because a quoted name can itself start with $:

command.CommandText = """SELECT $"$foo"::INT""";        // declares a parameter named $foo
command.Parameters.Add(new DuckDBParameter("$foo", 42));

One pass would let that entry answer for a declared foo.

Only $ is stripped. @ is DuckDB's absolute-value operator, so SELECT @name binds a column reference and no @ name can ever be declared.

IndexOf(string) gains the same tolerance, so a caller who adds $id can retrieve it by id.

Behaviour change

A declared parameter with no supplied value now throws before execution instead of letting the engine fail later with a message that named nothing. Code relying on the old behaviour was already producing a failed query. One assertion in ParameterCollectionTests.BindMultipleValuesInvalidOrderTest changed accordingly.

Positional binding is untouched.

Benchmarks

ParameterBindingBenchmark joins the existing suite. It caught a quadratic allocation in the prefix pass during review: the stripped name was materialised with Substring once per candidate, per declared parameter.

The numbers below are the prefixed path, which is the one that changed. NamedExact was the baseline and moved on neither axis.

  Binding 32 prefixed parameters, allocated per execution
- before   22,757 B
+ after     5,859 B

BenchmarkDotNet v0.15.4, macOS 26.3.1, Apple M2 Max, .NET SDK 10.0.301

Parameters	Allocated before	Allocated after	Reduction	Mean before	Mean after
1	1072 B	1040 B	3 %	32.75 μs	32.58 μs
8	3273 B	2121 B	35 %	104.71 μs	104.11 μs
32	22757 B	5859 B	74 %	411.43 μs	410.60 μs

Allocation is the whole gain. Time is unchanged, because a prepare and execute dominates the operation. Gen0 drops from 2.4414 to 0.4883 collections per 1000 operations at 32 parameters, and the prefixed path now allocates exactly what the exact path does.

The old code materialised the stripped name with Substring once per candidate, per declared parameter, so the cost grew with the square of the collection size. The new code compares a span and allocates nothing.

Verification

30 tests in NamedParameterTests.cs: prefixed and unprefixed names, quoted names that start with $ or consist of digits, repeated names, names differing only in case, multi-statement commands, and every case that must throw or must be ignored.

Check	Result
Full suite	7051 passed, 0 failed
NamedParameterTests	30 passed
Positional binding tests	unchanged and passing