…ies (erigontech#21597)

## Summary

Fixes the hive devp2p `BlobViolations` flake (`expected disconnect on
blob violation, got msg code: 24`) seen on the CI Gate run for erigontech#21524
(parallel leg) and on a runner-experiment branch the day before (serial
leg) — and the gossip-duplication regression behind it.

## Root cause

Since erigontech#21335 all per-eth-version sentry `GrpcServer`s share one
`p2p.Server` and one `PeerStore`. `SendMessageById` resolves the target
peer in the shared store, so callers that fan a by-id send out across
every sentry client — e.g. the txpool's new-peer pool sync
(`PropagatePooledTxnsToPeersList`) — now deliver the same frame once per
sentry: three identical `NewPooledTransactionHashes` messages per new
peer on the default eth/69+70+71 build. Before erigontech#21335 each sentry had
its own peer set, so the off-sentry sends were silent no-ops.

`SendMessageToAll` and `SendMessageToRandomPeers` already guard against
this with `protocolVersions.Contains(peerInfo.EthProtocol())`;
`SendMessageById` was the only outbound path without the
negotiated-version check.

The BlobViolations failure sequence, reproduced locally with wire-level
logging (hive `--sim devp2p --sim.limit eth` against an instrumented
image; failed on the second loop iteration with the exact CI error):

1. The test peers, announces two blob txs (one with a lying size/type),
delivers them, and waits for a disconnect.
2. The violating `PooledTransactions` reply sits in the txpool fetcher's
250 ms inbound batch before the announcement check kicks the peer.
3. If the 5 s `syncToNewPeersEvery` tick lands in that window, the
all-pool announcement (~70 KB — about 2000 hashes accumulated by earlier
suite tests) is written to the test peer three times:

```
08:16:32.606  inbound NPTH68            peer=de6008eb count=2
08:16:32.607  WRITE GET_POOLED_TXS_66   peer=de6008eb
08:16:32.607  sync-to-new-peers         entries=2002            <- 5s tick fires
08:16:32.608  WRITE NPTH68 70084 bytes  peer=de6008eb           <- one write
08:16:32.608  WRITE NPTH68 70084 bytes  peer=de6008eb           <- per
08:16:32.608  WRITE NPTH68 70084 bytes  peer=de6008eb           <- sentry
08:16:32.855  VIOLATION -> PenalizePeer peer=de6008eb           <- next 250ms batch flush
```

4. The devp2p test deliberately tolerates one pre-disconnect hash
announcement (go-ethereum commit 88c8459, Sept 2024, "sometimes we'll
get a blob transaction hashes announcement before the disconnect"); the
duplicated second copy arrives before the kick and fails the test.

In the failed CI run the timing lines up exactly: the txpool started at
06:33:04.64 and the test failed at 06:33:14.644 — the tick+10s sync.

With the duplication fixed, at most one announcement can precede the
disconnect in that window, which the test tolerates by design. Beyond
the test, every new peer was receiving the full pool sync in triplicate.

## Fix

Apply the same negotiated-eth-version guard in `SendMessageById` that
the other outbound paths use. Eth-protocol messages only; wit is
unaffected (it is deduplicated to a single `GrpcServer` at shared-server
construction). This also restores the routing contract documented at
`FetchBlockAccessLists` ("sentryIndex MUST be the sentry where peerID is
actually connected"): sends via a non-matching sentry are silent no-ops
again, as they were with per-sentry peer sets.

Not present on `release/3.4` (erigontech#21335 is main-only), so no backport is
needed.

## Testing

- New regression test
`TestGrpcServer_SendMessageById_SharedStore_NoDuplicateWrites` (TDD):
three `GrpcServer`s (eth/69/70/71) sharing a `PeerStore`, peer
negotiated eth/70, by-id fan-out across all three must produce exactly
one write. Red before the fix (`expected: 1, actual: 3`), green after.
- `go test ./p2p/sentry/... ./txnprovider/txpool/...` clean.
- Local hive validation in a loop: before the fix `not ok 18
BlobViolations` reproduced on iteration 2; after the fix 12/12
iterations green, with instrumented logs showing exactly one
`NEW_POOLED_TRANSACTION_HASHES_68` write per new peer where there were
three.
- `make lint` (repeatedly) and `make erigon integration` clean.

…vert

The initial revert paraphrased the PatriciaContext.Branch and TrieContext.Branch comments and trimmed one assertion from the unit test. Restore the exact pre-#21524 text and the full two-direction Test_TrieContext_BranchCopiesData, so the PR's net diff is precisely the inverse of #21524 and nothing else.

…proof/trace corruption (erigontech#21630)

**[SharovBot]**

## Problem

PR erigontech#21524 removed `common.Copy` from `TrieContext.Branch()`, claiming
the returned slice can be safely borrowed. However, mainnet RPC
integration tests show widespread failures:
- All 20 `eth_getProof` tests: diff mismatch
- 50+ `eth_simulateV1` tests: diff mismatch
- `debug_traceBlockByNumber`: malformed JSON + diff mismatch

The borrowed slice is being mutated before callers finish using it.

## Fix

Pure revert of erigontech#21524 (`b2329dc55b`). The net diff is exactly the
inverse of that commit and touches nothing else — equivalent to `git
revert b2329dc`. It:
- restores `common.Copy(enc)` in `TrieContext.Branch()` so each returned
slice is independent;
- restores the original `PatriciaContext.Branch` interface doc and
`TrieContext.Branch` comment;
- restores `Test_TrieContext_BranchCopiesData` in full, including the
original two-direction independence assertions (source mutation does not
reach the returned slice, and mutating the returned slice does not reach
the source).

## CI evidence

Failing job:
https://github.com/erigontech/erigon/actions/runs/26987787453/job/79641095034
Regressing commit: b2329dc

Fixes regression from erigontech#21524.

---------

Co-authored-by: erigon-copilot[bot] <erigon-copilot[bot]@users.noreply.github.com>
Co-authored-by: Giulio Rebuffo <giulio.rebuffo@gmail.com>
Co-authored-by: yperbasis <andrey.ashikhmin@gmail.com>
Co-authored-by: Andrew Ashikhmin <34320705+yperbasis@users.noreply.github.com>