chore(deps): move the theatron pins to v1.6.2

[forkwright]

theatron is our own repository and these pins sat two tags behind it — v1.6.0 against a released v1.6.2.

What is in the gap

Both are fix releases:

3bcde09 chore(main): release 1.6.2
9906675 fix(toolchain): build on stable rather than nightly
48cb9e7 chore(main): release 1.6.1
8a47e08 fix(repo): collapse the stale commit identities to one canonical author
db40336 test(parodos): isolate hyperlink environment probes
9905248 docs: repoint dead forge links at GitHub and derive the version pins

Code changes are confined to bathron/src/lib.rs, keryx/src/sse.rs and parodos/src/hyperlink.rs, plus test isolation. No API surface moved.

Bumped in both workspaces, because there are two

The root workspace and crates/theatron/proskenion carry independent lockfiles and independent declarations — six pin sites in the root manifest, five in proskenion. scripts/check-proskenion-pins.py fails when the two disagree on tag, features, or default-features, so bumping one is a broken tree rather than a partial improvement.

Their resolved sets legitimately differ, which is worth knowing before reading the lock diff: the root resolves parodos, themelion, gramma, bathron, keryx; proskenion resolves skeue in place of parodos. Neither lock carries the other's crate.

What is deliberately untouched

The version = "1.5.0" fields. They exist so cargo-deny can resolve the git dependency in the graph — the manifest comment says so — and they are a floor, not a claim about the version in use. theatron 1.6.2 satisfies ^1.5.0, so tightening them would add churn on every future bump and buy nothing.

Verification, before pushing

• scripts/check-proskenion-pins.py → proskenion theatron pins match root workspace
• cargo metadata --locked resolves in both graphs
• no v1.6.0 string remains in any of the four files

Noticed, not fixed here

skeue is declared in the root workspace dependencies but does not appear in the root Cargo.lock — nothing in that workspace consumes it. It is real and used in proskenion. That is an unused declaration rather than a pin problem, and it is not this PR's business.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud