refactor(sql): dialect-owned parameter markers, bind names and command configuration

ISqlDialect gains ParameterMarker (the token in the SQL text), ParameterBindName
(the DbParameter.ParameterName) and ConfigureCommand (per-command provider setup,
where Oracle will set BindByName). SQL Server and the test SQLite dialect answer
"@"+name for both spellings and no-op the hook, so SQL Server behaviour is
byte-identical — every existing expected-SQL assertion passes untouched.

SqlGroupPlanner drops its hardcoded @k/@w consts and mints base names (k0..kN, w)
that the dialect spells; SqlQueryPlan carries the emitted markers AND the matching
bind names, so SqlPollReader keeps copying the plan's pairing rather than
re-deriving a provider convention (the two diverge on ODP.NET: ":k0" in the text,
bare "k0" on the parameter). SqlCatalogLoader and SqlBrowseSession bind
schema/table through the dialect, so their bind names cannot drift from the
markers in the dialect-owned catalog SQL. Every parameter-carrying command site
calls ConfigureCommand before its first parameter.

Controlled by a new test-only ColonMarkerDialect (":name" markers, bare bind
names) that really executes against the SQLite fixture. Each leg was falsified
against the pre-change behaviour: the planner emitted "@k0", the reader bound
":k0", and a hardcoded "@schema" in the loader failed catalog load outright.

src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Sql.Dialect/SqlServerDialect.cs

@@ -27,6 +27,34 @@ public sealed class SqlServerDialect : ISqlDialect
     /// <inheritdoc/>
     public DbProviderFactory Factory => SqlClientFactory.Instance;
 
+    /// <summary>
+    ///     T-SQL markers are <c>@</c>-prefixed — <c>ParameterMarker("k0")</c> is <c>"@k0"</c>.
+    /// </summary>
+    /// <param name="baseName">The bare base name.</param>
+    /// <returns>The <c>@</c>-prefixed marker.</returns>
+    public string ParameterMarker(string baseName) => "@" + baseName;
+
+    /// <summary>
+    ///     Identical to <see cref="ParameterMarker"/>: <c>Microsoft.Data.SqlClient</c> expects
+    ///     <see cref="DbParameter.ParameterName"/> to carry the same <c>@</c> the statement does. (It also
+    ///     accepts a bare name and prepends the <c>@</c> itself, but spelling it out keeps the parameter
+    ///     collection readable in a profiler trace and matches what the SQL text says.)
+    /// </summary>
+    /// <param name="baseName">The bare base name.</param>
+    /// <returns>The <c>@</c>-prefixed bind name.</returns>
+    public string ParameterBindName(string baseName) => "@" + baseName;
+
+    /// <summary>
+    ///     No-op. <c>SqlCommand</c> binds by name out of the box, so there is nothing SQL Server needs set on a
+    ///     fresh command — the member exists for Oracle's <c>BindByName</c> (see
+    ///     <see cref="ISqlDialect.ConfigureCommand"/>).
+    /// </summary>
+    /// <param name="command">The command to configure; untouched here.</param>
+    public void ConfigureCommand(DbCommand command)
+    {
+        // Intentionally empty: see the summary.
+    }
+
     /// <inheritdoc/>
     public string LivenessSql => "SELECT 1";