fix(pg-compat): move the crates.io reader pin to 0.6.3

[dobby-coder]

Moves pg-compat's crates.io reader pin from =0.6.1 to =0.6.3, guards the
constraint that makes a same-minor pin impossible, and corrects the two
documents that describe it.

crates.io serves 0.6.3, 0.6.2, 0.6.1, 0.6.0, 0.5.10, …, so the 0.6 line's pin
was two patches behind the window COMPATIBILITY.md declares ("the highest
published patch of each line"). The 0.5 line's 0.5.10 was already correct.

What changed

• pg-compat/Cargo.toml: =0.6.1 replaced by =0.6.3, key renamed to
  match the existing convention. Not added alongside; see below.
• pg-compat/src/lib.rs: the reader! invocation and its readers() entry
  move to 0.6.3. Both places that resolve VERSION_V3 carry
  #[allow(deprecated)].
• pg-compat/Cargo.lock: regenerated. 0.6.3 is off the legacy irma chain
  (chore(pg-core): drop or replace the legacy irma 0.2.1 dependency #263), so it pulls reqwest 0.12 while the =0.5.10 pin keeps
  reqwest 0.11. Both lines now sit in that lockfile.
• pg-compat/tests/support_window.rs: new
  no_two_pinned_readers_share_a_minor_line.
• COMPATIBILITY.md: the crates.io row only. The npm and nuget rows are
  untouched.
• pg-compat/README.md: the "Adding a version" example moves to a cross-line
  version, and the constraint is stated with its reason.
• CLAUDE.md: the three bullets that named =0.6.1 as the pin.

#[allow(deprecated)] needs two attributes, not one

The issue asked for one line on the import. Measured, that is not enough: an
allow on a use item covers only the use, and the lint fires again on
pub const WIRE_VERSION: u16 = VERSION_V3;, which resolves the deprecated item
through that import. Reproduced against a scratch crate with the same shape:

warning: use of deprecated constant `inner::VERSION_V3`: old
  --> src/lib.rs:10:35
   |
10 |     pub const WIRE_VERSION: u16 = VERSION_V3;
   |                                   ^^^^^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

Under pg-compat-lint's -D warnings that is the same hard error the attribute
exists to prevent, so the const carries one too. Neither renames the constant;
the published crates only have the old name.

The guard, red

A real second 0.6.x pin never reaches the test. Cargo refuses to resolve the
manifest, which is the constraint itself:

$ cargo metadata --manifest-path pg-compat/Cargo.toml
error: failed to select a version for `pg-core`.
    ... required by package `pg-compat v0.0.0`
versions that meet the requirements `=0.6.3` are: 0.6.3

all possible versions conflict with previously selected packages

  previously selected package `pg-core v0.6.2`
    ... which satisfies dependency `pg-core-0-6-2 = "=0.6.2"` of package `pg-compat v0.0.0`

So the guard is shown red the way it is reachable: a second same-minor entry in
readers(), which is step 2 of the README recipe and the state someone lands in
before the manifest bites.

running 2 tests
test the_support_window_is_the_crates_io_reader_list_in_compatibility_md ... FAILED
test no_two_pinned_readers_share_a_minor_line ... FAILED

---- no_two_pinned_readers_share_a_minor_line stdout ----
thread 'no_two_pinned_readers_share_a_minor_line' panicked at tests/support_window.rs:42:13:
pg-compat pins both 0.6.3 and 0.6.2 on the 0.6 line; two same-minor `=` pins do
not resolve, because cargo unifies semver-compatible requirements to one
version. Replace the 0.6 pin instead of adding to it.

Both probes reverted afterwards; the tree here has neither.

Acceptance check

All four run green on this branch:

cargo run -p pg-core --features stream --example seal-samples -- /tmp/wire
PG_COMPAT_ARTIFACTS=/tmp/wire cargo test --manifest-path pg-compat/Cargo.toml --locked
cargo fmt --manifest-path pg-compat/Cargo.toml --all -- --check
cargo clippy --manifest-path pg-compat/Cargo.toml --all-targets --locked -- -D warnings

The gate is 13 tests over four targets, all passing: 0.6.3 opens every case in
the HEAD-sealed set, both modes, both recipients, no abort. Also ran the two
suites that read the same Reader list block, both green:
cargo test --manifest-path pg-core/Cargo.toml --features test,rust,stream
and PG_COMPAT_ARTIFACTS=/tmp/wire npm --prefix pg-compat-js test (23 pass,
0 cancelled).

Closes #352
Part of #327

[dobby-coder]

VERDICT: approve

Rules + review sign-off — cycle 1

The pin move is correct and every gate is green. Nothing here blocks. The review pass found three nits and no bugs, and rather than send the PR back for prose I fixed all three on the branch in 5777c20 — so the inline comments below are a record of what was found and what it turned out to be, not homework.

What I verified independently, not from the PR body

• crates.io really does put 0.6.3 at the top of the 0.6 line. The index serves 0.3.0-rc.0 … 0.3.1, 0.5.6 … 0.5.10, 0.6.0, 0.6.1, 0.6.2, 0.6.3, so =0.6.3 and =0.5.10 are the highest published patch of each line — which is exactly what COMPATIBILITY.md declares the window to be. The PR body's version list is accurate.
• All four acceptance commands, re-run here. seal-samples writes the set; cargo test --manifest-path pg-compat/Cargo.toml --locked is 13 tests over four targets, all passing (10 + 0 + 2 + 1, matching the body's count); cargo fmt -- --check exits 0; cargo clippy --all-targets --locked -- -D warnings exits 0. cargo test -p pg-core --features test,rust,stream is green too.
• The new guard has teeth, measured rather than argued. Adding a second 0.6.x entry to readers() fails no_two_pinned_readers_share_a_minor_line with the exact message the body quotes. And the fix in the second comment below is not cosmetic: with the original major.minor bucketing, a tree pinning both 1.0.0 and 1.1.0 left that test reporting ok — silent green on precisely the collision it exists to catch. With the fix it fails, naming both. Both probes were undone with the inverse edit; git status is clean against the pushed commit.
• The .gitattributes CRLF trap does not apply to this suite, which is worth recording because two sibling gates in this repo family did have it. tests/support_window.rs reaches COMPATIBILITY.md through parse_crates_io_readers, and that parser is text.lines() plus line.trim() / trim_start() throughout, anchored on a single-line HEADER constant. Rust's str::lines() strips a trailing \r, so a Windows checkout parses identically. No multi-line anchor, no r##" literal, nothing to pin — the two entries the root .gitattributes does carry are for the spec-mutation gates, which is the shape that needs it.
• Dropping the #268 reference from CLAUDE.md is correct, not a lost pointer — #268 is closed. Same for the code comment's #339: that is the issue, closed by #345, which is the commit that actually added the in-tree deprecation.
• The lockfile carrying both reqwest lines at once is right: 0.6.3 is off the legacy irma chain and pulls reqwest 0.12, while =0.5.10 still drags 0.11.27. Visible in the clippy run, which checks irma v0.2.1 and irmars v0.2.2 side by side.

Why the three nits were worth a commit and not a loop

All three were accuracy, not behaviour. The load-bearing one is the first: the PR's own reasoning about #[allow(deprecated)] is sound in principle but was reproduced against a scratch crate rather than the real dependency, and the resulting prose described a constraint as in force when it is preemptive. CLAUDE.md is auto-loaded agent context, so a wrong constraint there is the kind of thing a later run acts on. Fixing the file and leaving the same sentence standing in CLAUDE.md would just have re-found it next round, so both surfaces moved together.

One thing I introduced and then corrected in the same commit: generalising minor_line past 0.x made the guard's own panic text ("two same-minor = pins") wrong for the 1.x case it now catches, along with the matching sentences in README.md and CLAUDE.md. All three now say compatibility bucket and spell out the 0.x / 1.0.0-on split.

State

Gates re-run green on 5777c20 before pushing. CI was still in flight at review time; I flip this out of draft once it lands green, and it then needs a maintainer approval — the bot cannot self-approve, which is why this is a COMMENT carrying VERDICT: approve rather than an APPROVE.

[rubenhensen]

/dobby solve conflicts

[dobby-coder]

On it — I'll take a look at PR #354, sort out the merge conflicts, and push the resolution to the branch.

[dobby-coder]

Done, but you beat me to the merge button! I resolved the CLAUDE.md conflict on #354 (kept this branch's 0.6.3 wording plus both bullets #351 added) and pushed it as ec75a54. While I was verifying it, you squash-merged as f095557 — so main now has the resolution, no PR left to act on.

Verified against the merged tree: pg-compat gate (13/13), pg-compat-js (23/23), pg-core suite, fmt/clippy, and the wasm suite under Node. The red "wasm tests in browsers" checks aren't related to the conflict — firefox failed to install via apt in CI, which cancelled the rest of that matrix; my run on f095557 itself is green. I also cleaned up four inline review threads that were already answered but left open.

One loose end: while checking the --node docs bullets #351 added, I found they're slightly off — window() also lives in test_rust_to_rust, so 4 tests fail under --node, not 2, and the filter needs a second -- (wasm-pack test --node ./pg-wasm -- -- <name>). I pushed a fix for that as 14f2148 just before noticing the merge, so it never made it into a PR. git cherry-pick 14f2148 if you want it, or let me know and I'll open it as its own PR.