feat: register databases by key and validate paths at setup

[onehumandev]

Replace path-as-identifier IPC with explicit key registration so the frontend and Rust callers open databases by stable keys (e.g. "MAIN") instead of filesystem paths. Paths are resolved once in Rust during plugin setup, validated, and cached; later opens only look up the key.

Problems solved:

• Security: untrusted frontend can no longer supply arbitrary paths over IPC; unknown keys fail with PATH_NOT_REGISTERED.
• Cross-language identity: avoids TS/Rust path string mismatches (separators, symlinks, canonicalization) on every load.
• Runtime path discovery: on_setup + SetupRegistrar register paths from app.path() / platform resolvers once, without repeat JNI or resolver work on each open.
• Consistent open path: load, Connection::connect, and migrations share connect_to_database and the same DbInstances cache, along with assurance that migrations have completed before connecting to the database.
• Safer registration: validate_database_path rejects relative paths, traversal, null bytes, and canonicalizes file paths at startup (fail-fast INVALID_PATH / PATH_TRAVERSAL).

API changes:

• add_migrations(path, migrator) → register_database(key, path, migrator?) (returns Result; adds Builder::on_setup / SetupRegistrar)
• IPC/command args: db → dbKey; attached databasePath → databaseKey
• MigrationEvent: adds dbKey, dbPath is now absolute PathBuf
• TransactionToken: dbPath → dbKey
• Connection trait on AppHandle for Rust-side opens by key

Also: expose canonicalize_database_path from conn-mgr, tighten is_memory_database query-param matching, add toolkit :memory: tests, update README/guest-js rustdoc, and add validate.rs (replaces load-time path resolution in resolve.rs).

[velocitysystems]

Great work carrying over the improvements from #50. Just a couple of observations:

• Keys are now indirected to paths, and nothing dedupes them. Two keys pointing at the same file create two independent DbInstances pools over one store.
• remove() is frontend‑reachable and deletes the file, orphaning the other key's live pool; close() can tear down a shared handle; per‑key migrations double‑run against one file.
• For named shared‑cache :memory: URIs it's worse — closing one pool can destroy the in‑memory store the other key is still using.

Should we fail‑fast on duplicate canonical paths at register_database, or guard teardown by reverse‑indexing canonical paths?

[onehumandev]

Great work carrying over the improvements from #50. Just a couple of observations:

• Keys are now indirected to paths, and nothing dedupes them. Two keys pointing at the same file create two independent DbInstances pools over one store.
• remove() is frontend‑reachable and deletes the file, orphaning the other key's live pool; close() can tear down a shared handle; per‑key migrations double‑run against one file.
• For named shared‑cache :memory: URIs it's worse — closing one pool can destroy the in‑memory store the other key is still using.

Should we fail‑fast on duplicate canonical paths at register_database, or guard teardown by reverse‑indexing canonical paths?

Addressed here