v0.1.0-alpha.4 — Nirdosha now speaks the Rust ecosystem

Nirdosha now speaks the Rust ecosystem

db_connect/mq_connect_via dispatch by URL scheme to a plugin at
runtime — so any backend a Rust crate exists for is reachable from
plain Nirdosha source, with no new syntax:

db_connect("mysql://user:pass@host/db")     // -> a MySQL-backed `db` handle
mq_connect_via("activemq://host:61613")     // -> an ActiveMQ-backed `mq` handle

db_query/db_execute/mq_publish/mq_consume/stop all work
unchanged on the resulting handle — the same affine db/mq types,
the same Result(_, str) error convention, the same parameterized-query
discipline every built-in SQLite/Postgres/Redis call already has. A
program written against db_connect/mq_connect_via doesn't know or
care which backend answered — that's decided entirely by the
scheme:// prefix, resolved against whatever plugins the host process
was started with.

Five real reference plugins, not a toy example

Each is a genuine Rust crate wrapping a real client library, reviewed
and listed in TRUSTED_PLUGINS.md:

Plugin	Backend	Rust crate
nirdosha-plugin-mysql	MySQL	mysql (sync)
nirdosha-plugin-activemq	ActiveMQ	hand-rolled STOMP client
nirdosha-plugin-cassandra	Cassandra	scylla (async)
nirdosha-plugin-neo4j	Neo4j	neo4rs (async)
nirdosha-plugin-hbase	HBase	hbase-thrift

The async ones bridge through nirdosha-plugin-support's
shared runtime + HandleRegistry, proven out end-to-end starting with
the simplest case (nirdosha-plugin-mysql, deliberately built first
since its sync client is closest in shape to the built-in SQLite path).

Writing your own

No registry, no submission process — a plugin is an ordinary Rust
crate that registers db_provider_<scheme>_connect/query/execute or
mq_provider_<scheme>_connect/publish/consume builtins and gets
statically linked into whatever binary calls run_with_plugins/
serve::run. The full recipe, worked end-to-end against all five
reference plugins above, is in
docs/PLUGIN_AUTHORING_FOR_LLMS.md.

Honest scope, disclosed rather than implied: a Kind-A plugin is full
native-process trust, no sandbox (see TRUSTED_PLUGINS.md and
rfcs/0004-native-plugin-sandboxing.md for exactly what "trusted"
does and doesn't mean here) — appearing in the trust list means a
maintainer read the source, not that isolation exists.

Full design writeup: docs/adr/0004-external-data-service-boundary.md.

v0.1.0-alpha.3

v0.1.0-alpha.3 - Windows TCP port

v0.1.0-alpha.2

v0.1.0-alpha.2 - fixes macOS release build

v0.1.0-alpha.1

v0.1.0-alpha.1 - first tagged release