User-protection guard against a fat-fingered fee on the
sendrawtransaction JSON-RPC. This is NOT consensus or policy
enforcement — an absurd-fee tx is a perfectly valid transaction that
miners would accept; the only reason to reject it is operator safety.

Deliberately divergent from bitcoin-sv's placement. svnode enforces
the ceiling inside its validator's TxnValidation pipeline because it
passes a per-call nAbsurdFee from RPC down to the validator
(allowhighfees=true → Amount(0) → disabled for that call). We do not
mirror that placement: svnode's P2P path uses DEFAULT_TRANSACTION_MAXFEE
(0.1 BSV) which doesn't reject anything realistic, so the
validator-level placement gives no real protection beyond the RPC
entry point. Putting it in our validator would pollute the policy
path with a check that exists purely to catch a fat-fingered RPC
call. Operators needing strict svnode parity can later add an
Options.AbsurdFeeCeiling to the validator; the seam stays clean.

- New Policy.MaxRawTxFee (uint64 sats); default 10M = 0.1 BSV,
  matching bitcoin-sv DEFAULT_TRANSACTION_MAXFEE = COIN/10. Wired
  through settings.NewSettings via getUint64("maxrawtxfee", …) so
  the runtime default is non-zero — the struct tag alone is
  decorative. Settings-wiring tests pin default, env-override, and
  env-zero opt-out.
- handleSendRawTransaction extends the tx (RPC arrives as wire
  bytes), computes fee = inputSats - outputSats, and rejects with
  `absurdly-high-fee <fee> > <ceiling>` when over the cap.
  allowhighfees=true bypasses; MaxRawTxFee=0 disables globally.
- After PreviousOutputsDecorate succeeds, call tx.SetExtended(true)
  so the downstream validator does not re-decorate and the gRPC
  client serialises extended bytes instead of wire bytes.
- rpcserverhelp.go updated (was: "has no effect").

Tests: 5 handler-level (below ceiling accept; above ceiling reject
with full error-string assertions; allowhighfees bypass; ceiling=0
disables; help-text drift pin) + 3 settings-wiring.

Pt.1 of a 3-part fix for the consensus bug PR review identified in
the original T13 commit (f56e5cd): in-block parents can be wrongly
stamped with unconfirmedParentHeight, surfacing
bad-txns-unconfirmed-input-in-block on blocks svnode accepts.

The root cause has two paths, but a prerequisite for fixing either
is that Options.ParentMetadata reaches the validator in distributed
mode (UseLocalValidator=false, production default). Today it
doesn't: the proto has no parent_metadata field and the HTTP fallback
sends raw tx bytes plus lossy query-string scalars only. The metadata
is silently dropped on every wire crossing. This commit closes that
wire gap. No behavioural change in isolation — pt.2 (validator-core
preservation across the extend==true fallthrough) and pt.3
(block-scoped accumulator + per-tx filtered metadata in
subtreevalidation) need this wire to be in place first.

- Proto: new ParentTxMetadata message (bytes parent_hash, uint32
  block_height) and repeated parent_metadata on
  ValidateTransactionRequest. bytes parent_hash carries the
  chainhash.Hash internal byte order directly — no hex encoding,
  no display-order conversion, no risk of round-tripping to the
  wrong key.
- Client: buildValidateTxRequest now marshals Options.ParentMetadata
  via a new parentMetadataToWire helper, with a defensive 32-byte
  copy per entry so the wire form does not alias the source map.
- Server: optionsFromValidateRequest reconstructs the in-memory map
  via parentMetadataFromWire. Fails closed on malformed entries
  (nil or wrong-length parent_hash) with a request-level error
  rather than silently dropping — silent drop would resurrect
  exactly the consensus rejection shape this PR series is meant to
  remove. Error is propagated through both the gRPC handler and the
  HTTP-fallback batch retry path in Client.go.
- HTTP fallback: validateTransactionViaHTTP now sends
  application/x-protobuf with a marshalled ValidateTransactionRequest
  in the body. Server's handleSingleTx discriminates on Content-Type
  and falls back to the legacy raw-body + query-string path for
  non-protobuf callers (backward compatible with any existing
  non-protobuf client).

Tests in services/validator/parent_metadata_api_test.go cover:
proto round-trip; empty/missing field; full Client → Server
round-trip; non-symmetric-hash byte-order pin (catches any future
drift to a hex-encoded string key); defensive-copy invariant;
isProtobufContentType across 10 Content-Type variants; HTTP
protobuf-body end-to-end; legacy octet-stream backward-compat;
fail-closed on nil entry; fail-closed on 5 malformed-length
variants.

…3 fix pt.2]

Pt.2 of 3 (continues b472731b3 / pt.1 wire prep). Closes Path 1 of
the consensus bug PR review identified in the original T13 commit
(e03ad5c): the extend==true fallthrough in
getUtxoBlockHeightAndExtendForParentTx silently overwrites the
candidate height that ParentMetadata supplied for an in-block
parent.

When extend==true and the parent appears in ParentMetadata, the
function correctly stamps the candidate height up front but must
also fetch the parent tx body from the UTXO store for input
extension. The post-Get height-stamping block was unconditional:
in-block parents have empty BlockHeights (Create writes the tx row
but the blocks_transactions join row is only added by
SetMinedMulti) so the "empty → sentinel" branch fires and clobbers
the candidate height with unconfirmedParentHeight. The BDK adapter
then translates that to MEMPOOL_HEIGHT and rejects with
bad-txns-unconfirmed-input-in-block on a perfectly legitimate
block — chain-split risk in consensus mode.

This commit adds a cameFromParentMetadata flag and gates the
post-Get stamping on !cameFromParentMetadata. The Get call still
happens (input extension needs the parent tx body); only the
height stamping is skipped for the affected indices.

Tests in services/validator/Validator_test.go:

- _ParentMetadataPreservedThroughExtendFallthrough — positive pin:
  candidate height survives extend==true; PreviousTxSatoshis /
  PreviousTxScript populated from the parent body with deliberately
  distinctive values (placeholder vs parent value are different, so
  the assertion cannot pass by accident if extension never ran).
- _UnconfirmedSentinelOnlyAppliedWhenNoParentMetadata — negative
  drift pin, sharp != sentinel assertion to catch any future
  refactor that reintroduces an unconditional overwrite.
- _FallbackWritesUnconfirmedSentinel reinforced with an explicit
  Options.ParentMetadata == nil assertion so its intent (the
  no-ParentMetadata code path) is pinned, not implicit.

Sanity-checked: temporarily disabling the gate fails the
preservation pin at the height assertion (expected 12345, got
0xffffffff), confirming the test catches the regression shape.

Pt.3 still needed for the rest of the consensus fix:

- Path 2 (skip-level parents) — a tx spending an in-block
  grandparent is not in ParentMetadata at all because the current
  builder only fills level-1.
- Cross-batch in-block parents in CheckBlockSubtrees — batch 1's
  parent is not in batch 2's local ParentMetadata.
- Per-tx filtered metadata to avoid O(N²) wire bandwidth in
  distributed validator mode (every per-tx gRPC call currently
  serialises the full block-scoped accumulator).

…[pt.3]

Plumbs ParentMetadata through block-validation so the validator can answer
"is this in-block parent confirmed?" for every tx in a block — not just the
level-1 children that have a direct UTXO-store hit AND not just the
subtree-being-validated, but every parent the candidate block contains.

Without this, in-block parents fall through to the UTXO-store BlockHeights
path, find them empty (the parent's blocks_transactions row is only written
by SetMinedMulti after the block is accepted), the validator stamps
unconfirmedParentHeight, and BDK rejects legitimate blocks with
bad-txns-unconfirmed-input-in-block.

Block-scoped accumulator spans all batches and the ordered-retry phases:

- CheckBlockSubtrees hoists a single map[chainhash.Hash]*ParentTxMetadata
  for the whole block, wrapped in a parentMetadataAccumulator composite
  (snapshot + delta — see below).
- processTransactionsInLevels / processMissingTransactions: per-tx wire
  bandwidth is bounded by filterParentMetadataForInputs, which returns
  only the accumulator entries referenced by the tx's input prevouts (nil
  when there are no matches, so the proto field is absent on the wire).
  After each level's g.Wait(), successful-tx hashes are merged into the
  accumulator under first-writer-wins semantics.
- Already-known txs that hit the cache/store pre-check (e.g. validated
  earlier via the peer-announced subtree path) are seeded into the
  accumulator at the candidate block's height BEFORE the missed==0 early
  return — closing the gap where a child of such a parent in the same
  block would otherwise fall through to the UTXO-store BlockHeights path
  and trigger bad-txns-unconfirmed-input-in-block.
- validateMissingSubtreesWithOrderedRetryAccumulated splits Phase 2
  (parallel) from Phase 3 (sequential) for the block-validation ordered
  retry. Phase 2 hands each goroutine a parentMetadataAccumulator with a
  SHARED read-only snapshot of the live accumulator + a small fresh
  per-subtree delta — no per-subtree full-copy. After g.Wait(), only
  fully-successful subtrees' (small) deltas merge into the live
  accumulator in block-subtree order. Failed-Phase-2 deltas are dropped;
  those subtrees retry in Phase 3 against the live accumulator
  sequentially. This preserves consensus determinism: failed-Phase-2
  partial writes never enter the accumulator.
- ValidateSubtreeInternal stays as a public shim over a private
  validateSubtreeInternalImpl that accepts the block accumulator; the
  public signature is unchanged.

Tests:
- TestProcessTransactionsInLevels/SeedsAlreadyKnownTxsIntoAccumulator —
  regression for the "parent already in store/cache, child missing in
  same block" scenario. Sanity-verified by temporarily disabling the
  seeding code; test correctly fails.
- TestParentMetadataAccumulatorAdd — first-writer-wins semantics
  (subsequent adds for the same hash are no-ops, regardless of whether
  the prior entry came from snapshot or delta).
- TestFilterParentMetadataForInputs — match/miss/empty/nil-tx/duplicate
  cases plus snapshot+delta-read-merge and delta-wins-over-snapshot.
- TestValidateMissingSubtreesWithOrderedRetryAccumulated_Phase2DeltasMergeAfterWait
  — pre-seeds the live accumulator and asserts every Phase 2 goroutine
  sees the seed via the shared snapshot AND enters with an empty delta
  (proves both snapshot sharing and delta isolation).
- TestValidateMissingSubtreesWithOrderedRetryAccumulated_FailedPhase2DoesNotContribute
  — pins that failed-Phase-2 partial contributions are dropped; Phase 3
  retry's contributions reach the live accumulator.

… wiring

Adds TestCheckBlockSubtrees_AssembledPath_SkipLevelAndMixedParent, an
end-to-end test that drives the full CheckBlockSubtrees pipeline (parse →
batch → level-order → per-tx filter → validator) against a candidate
block whose DAG exercises both shapes the consensus-split bug surfaced
through:

  - a skip-level grandparent dependency (C at level 2 spends both P AND
    G directly — the C → G edge crosses one level);
  - a mixed in-block + confirmed external parent (C also spends Gext,
    which lives in the UTXO store with BlockHeights=[99] and must NOT
    enter the block-scoped accumulator).

DAG: G has 2 outputs; P spends G.vout 0 (level 1); C spends P.vout 0 AND
G.vout 1 (level 2 — the G edge is the skip-level case) AND Gext.vout 0
(the confirmed external case). C also referencing P is load-bearing for
the skip-level claim — without that edge the level builder would place
C at level 1 alongside P, and a previous-level-only buildParentMetadata
implementation would still feed G to C correctly, making the test
vacuous.

The test guards that structural invariant directly: a pre-flight check
calls server.selectPrepareTxsPerLevel and asserts maxLevel=2 with
G@level 0, P@level 1, C@level 2. A future refactor of the level builder
or accidental DAG edit that re-collapses the skip-level shape is caught
before the per-tx assertions run.

A recording wrapper around MockValidatorClient captures the resolved
Options per-tx as a slice — BOTH processTransactionsInLevels (batch
loop) and the ordered-retry processMissingTransactions call
ValidateWithOptions for each tx, and the test asserts the accumulator
wiring is correct on BOTH pipelines, not just whichever one happened to
be called last. The wrapper also returns Data with TxInpoints populated
from NewTxInpointsFromTx(tx) so the downstream subtreeMeta serialisation
in validateSubtreeInternalImpl succeeds.

Assertions walk every recorded call:

  - G's ParentMetadata empty in every call (no in-block parent).
  - P's ParentMetadata[G] present at candidate height in every call.
  - C's ParentMetadata[G] present at candidate height in every call —
    the regression assertion that pins skip-level survival.
  - C's ParentMetadata does NOT contain Gext in any call — guards
    against an over-eager refactor that seeds confirmed externals at
    candidate height (which would break CSV/locktime).
  - response.Blessed == true.

Sanity-verified two ways:
  1. Blanked ParentMetadata in each of the two pipelines in turn — test
     fails for both, naming the at-fault pipeline by call index.
  2. Simulated a previous-level-only buildParentMetadata(txsPerLevel[level-1])
     behaviour in processTransactionsInLevels — test fails at the
     skip-level C → G assertion, the precise bug shape.

Closes the gap left after the accumulator commit: every component was
tested individually, but nothing drove the assembled orchestration
end-to-end. Guards against a future refactor silently re-opening the
consensus-split path even when component tests stay green.

Also strips reviewer-attribution wording from comments in
check_block_subtrees_test.go and parent_metadata_accumulator_test.go —
documentation describes behavior, not provenance.

Verified: go build, go vet, gofmt clean. Test passes; both sanity
teardowns correctly fail and name the at-fault pipeline.