Named Placeholders Fail with Embedded Replica

[mkrenzke]

Bug Report: Named Placeholders Fail with Embedded Replica

Describe the Bug
When using named placeholders ($bar) in queries with an embedded replica, execution fails with a panic. However, using positional placeholders (?) works correctly.

Steps to Reproduce
Run the following JavaScript snippet:

import { createClient } from "@libsql/client";

const client = createClient({
  url: "file:local.db",
  syncUrl: "libsql://[db-slug]-[org-slug].turso.io",
  authToken: "..."
});

await client.execute('create table if not exists foo (bar text)');

// Works - with positional placeholder
await client.execute({
  sql: 'insert into foo (bar) values (?)',
  args: ['baz']
});

// Fails - with named placeholders (only when syncUrl is set)
await client.execute({
  sql: 'insert into foo (bar) values ($bar)',
  args: { bar: 'baz' }
});

Expected Behavior
The named placeholder syntax should function identically to positional placeholders and successfully execute the query.

Actual Behavior
The query fails when using named placeholders, causing a panic with the following error message:

thread '<unnamed>' panicked at src\statement.rs:394:62:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:     0x7ff9b2290aaa - napi_register_module_v1
   1:     0x7ff9b1f4752b - napi_register_module_v1
   2:     0x7ff9b2283ca1 - napi_register_module_v1
   ...
  42:     0x7ffa368a7374 - BaseThreadInitThunk
  43:     0x7ffa3841cc91 - RtlUserThreadStart

Environment

• libSQL Version: 0.5.3
• @libsql/client Version: 0.15.1
• Node Version: 22.9.0
• Operating System: Windows 10
• Replication Setup: Embedded replica with syncUrl

Additional Context

• The issue only happens when syncUrl is configured. Without syncUrl, named placeholders work fine.
• The panic occurs at src\statement.rs:394:62, suggesting an issue with how named placeholders are processed internally in the replication context.