docs(deps): correct the retired-patch comment and record the chia-0.36 cascade blocker

[MichaelTaylor3d]

What this PR is, and what it is NOT

WU4 of DIG-Network/dig_ecosystem#2761 asked for the whole dig-node workspace to move from
chia 0.26 / chia-wallet-sdk 0.30 to chia-protocol 0.36.1 / chia-wallet-sdk 0.34, in one unit,
verified by cargo tree -d reporting no duplicates.

That is not achievable by any edit to this repo. The brief said to report the shape rather
than half-land it, so this PR carries only the manifest-comment correction the brief also asked
for, plus the measurement recorded where the next lane will read it.

The blocker, measured

chia-protocol 0.26.0 enters this workspace through a path no dig-node manifest can edit:

dig-node-core
-> dig-gossip (git rev 51054a41, unpublished)
-> dig-peer-protocol 0.6.0
-> chia-sdk-client 0.28.0
-> chia-protocol 0.26.0

• dig-peer-protocol 0.6.0 is the ONLY published 0.6.x, and it declares chia-protocol = "0.26",
  chia-sdk-client = "0.28", chia-traits/chia-sha2/chia-ssl/chia_streamable_macro = "0.26".
  There is no 0.7. ^0.6 can therefore only ever resolve to the 0.26 line.
• dig-peer-protocolmain is still version = "0.6.0" on chia-protocol = "0.26" — the uplift
  has not been started there.
• dig-gossipmain (0.28.0) still declares dig-peer-protocol = "0.6" and chia-protocol = "0.26".
  It is unpublished, and its publish is itself guarded pending dig-peer-protocol (#681).

So WU4 is a release-first cascade across three repos, not a single-repo edit:
dig-peer-protocol -> dig-gossip -> dig-node.

Why landing the dig-node half alone would be worse than not doing it

crates/dig-node-core/src/seams/dig_peer/store_melted.rs:44 imports Bytes32 from dig_gossip
(i.e. chia-protocol 0.26). The same file drives digstore_chain's ChainReads trait, whose
push(SpendBundle) / estimate_fee(SpendBundle) (:1378,:1381) sit beside confirm_melt_via_chain
— the read that authorizes a store DELETE.

Uplifting dig-node alone moves digstore-chain/chia-protocol to 0.36.1 while dig_gossip keeps
handing this file 0.26 Bytes32. Those become two different types inside the melt-authorization
path, forcing precisely the cross-version Bytes32/SpendBundle shim the epic exists to remove.
profile_sync.rs:78 crosses the same boundary.

Everything else is ready — the cascade is the only thing missing

Verified on crates.io, all already on chia-protocol 0.36.1 / chia-wallet-sdk 0.34:

dep	now	target
chia-peer	0.1.3 (pinned "0.1")	0.2.0 (0.36.1/0.34) or 0.3.0 (via chia-query 0.15)
chia-query	=0.5.1 + 0.6.2 (two lines)	0.15.0 — the migration does require this, since 0.6.2 depends on chia ^0.26
dig-chainsource-interface	0.1 + 0.2 (two lines)	0.3, unified by chia-query 0.15 + chia-peer 0.3
datalayer-driver	3.0.0	4.0.0
dig-wallet-backend	0.4.0	0.29.0
dig-merkle	0.4.5	0.8.0
dig-clvm	0.2.2	0.3.0
dig-constants	0.9.0 (pinned)	0.10.1
dig-peer-protocol	0.6.0	does not exist <- the blocker

The chia = "0.26" umbrella (dig-node-service/Cargo.toml:229, dig-wallet/Cargo.toml:35) is
confirmed unbumpable: the published chia versions go ... 0.29.0, 0.32.0, 0.42.0 ... with no 0.36,
so those two declarations must be replaced by the individual facade crates. That replacement is
straightforward and is part of the dig-node unit once the cascade unblocks it.

Correction to the epic's acceptance criterion

cargo tree -d can never be clean for chia-bls, chia-sha2 or chia-traits, even after a perfect
migration. chia-wallet-sdk 0.34's own tree contains four chia-bls lines simultaneously:

• 0.28.2 via clvmr 0.16.4 (which chia-protocol 0.36.1 itself requires)
• 0.42.1 via chialisp 0.4.6 <- chia-sdk-types 0.34
• 0.22.0 via clvm_tools_rs 0.3.0 <- chia-sdk-types 0.34
• 0.36.1 via chia-protocol 0.36.1

These are upstream-internal and do not cross any DIG API boundary. The checkable invariant should be
one chia-protocol, one chia-wallet-sdk, one chia-query, one dig-chainsource-interface, one
chia-sdk-* — the types that actually cross our trait boundaries.

What is in the diff

• crates/dig-node-core/Cargo.toml:219-239 — the dig-gossip comment claimed the vendored
  chia-protocol/chia-sdk-client forks are re-declared in the workspace [patch.crates-io]. That
  section is RETIRED (root Cargo.toml:43); dig-gossip 0.23.0 deleted both forks. Corrected, and the
  blocker above recorded at the declaration that causes it.
• crates/dig-node-core/Cargo.toml:244-245 — same stale [patch.crates-io] reference in the
  dig-constants rationale, repointed.
• Cargo.toml — workspace version 0.136.2 -> 0.136.3.

Blast radius

Comment-only plus a version string. No symbol is edited, so no impact query applies; per CLAUDE.md
§2.0 bound (2) the analysis was done by resolution instead — cargo metadata succeeds and
Cargo.lock is byte-identical apart from the workspace version bump, which is the strongest
available evidence that the dependency graph is untouched.

Version bump

Patch (0.136.2 -> 0.136.3). Comments and a version string; no behaviour change, no API change,
no resolution change.

Refs: DIG-Network/dig_ecosystem#2761