Workspace crate versioning policy is unstated and already inconsistent

[jjhafer]

crates/sqlx-sqlite-toolkit/Cargo.toml carries the comment
# Sync major.minor with major.minor of SQLx crate. That policy structurally
cannot express a breaking change in the crate: under Cargo's 0.x rules the minor
position is the compatibility position, but the policy pins minor to SQLx's.
PR #55 was the first change to collide with it (a behavioural break in
DatabaseWrapper::enable_observation() shipped as 0.9.0 → 0.9.1).

In practice nothing broke, because sqlx-sqlite-toolkit is not published on
crates.io, cannot currently be packaged at all (cargo package fails — its
dependencies lack version requirements), and its only consumer depends on it by
bare path. So no consumer can pin a version. But the policy comment implies
otherwise, and the drift is already visible:

• crates/sqlx-sqlite-toolkit/README.md lines 29 and 32 still instruct consumers
  to use version = "0.8" while the crate is at 0.9.1
• sqlx-sqlite-conn-mgr is at 0.9.0 while its two siblings are at 0.9.1 — and
  conn-mgr is published (0.8.6 on crates.io), so it is the one where the policy
  actually has consequences

Worth an explicit decision recorded somewhere: which crates are intended to be
publishable, whether the SQLx-sync policy applies to all of them, and how a
breaking change gets expressed under it. Options include decoupling from SQLx's
version and recording compatibility in metadata, or marking the workspace-internal
crates publish = false. The repo has no ADR convention today, so this is an issue
rather than ADR material unless one is introduced.

---

Split out of the code review on #55, where it was validated as real but out of scope for that PR. See the review threads there for the supporting analysis.

Issue filed by AI model Claude