Library split, README rewrite, BUILD correctness and supply-chain gates

.github/dependabot.yml

@@ -0,0 +1,28 @@
+version: 2
+updates:
+  # One Cargo workspace at the root, so one entry covers all four crates.
+  - package-ecosystem: cargo
+    directory: /
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+    groups:
+      # Patch/minor churn as one PR; majors stay separate so they get read.
+      minor-and-patch:
+        update-types: [minor, patch]
+    # A Cargo.lock bump changes the crate_universe resolution, and MODULE.bazel.lock
+    # with it. The `lockfile` CI job regenerates and commits that automatically,
+    # so no manual repin step is needed -- but expect a follow-up bot commit.
+    commit-message:
+      prefix: "deps"
+
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: monthly
+
+  # Keeps bazel_dep versions in MODULE.bazel current.
+  - package-ecosystem: bazel-modules
+    directory: /
+    schedule:
+      interval: monthly

.github/workflows/ci.yml

@@ -147,3 +147,14 @@ jobs:
                      -m "Regenerated by CI from MODULE.bazel. Pins the resolved module graph and the registry file hashes that bcr.bazel.build served; --config=locked verifies it."
           git push
           echo "::notice::MODULE.bazel.lock was regenerated and committed."
+
+  # Supply chain: licenses, RustSec advisories, banned/duplicate crates, and
+  # that every source is the real crates.io registry.
+  supply-chain:
+    name: cargo-deny
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: EmbarkStudios/cargo-deny-action@v2
+        with:
+          command: check

CONTRIBUTING.md

@@ -53,6 +53,20 @@ the run that verifies it -- `--config=locked` validates the new lock on the
 *next* push. That is deliberate (it is also what stops the job looping), but it
 means a freshly regenerated lock is checked one run later than you might expect.
 
+In practice that shows up like this: **the first CI run on a PR that changes
+`Cargo.toml` or `Cargo.lock` will have a red `bazel` job**, reporting
+
+```
+ERROR: MODULE.bazel.lock is no longer up-to-date because: One or more files the
+extension '@@rules_rust+//crate_universe:extensions.bzl%crate' is using have changed.
+```
+
+That is the drift check working, not a broken build. The `lockfile` job in the
+same run has already regenerated the lock and pushed it; the next push to the
+branch goes green. This is deliberately left as a visible failure rather than
+folded into the bazel job: if the lock were silently regenerated before every
+build, `--lockfile_mode=error` would never actually catch anything.
+
 Check whether yours is current:
 
 ```sh

Cargo.toml

@@ -23,3 +23,7 @@ version = "0.1.0"
 edition = "2024"
 # Keep in sync with rust-toolchain.toml and rust.toolchain() in MODULE.bazel.
 rust-version = "1.94"
+# Nothing here is published to crates.io. This also lets cargo-deny treat these
+# crates as private and skip the license check they would otherwise fail, since
+# none of them declares a license.
+publish = false