#36328 p2p: Reconsider package transactions that are immediately trimmed

Updates `AcceptPackage` validation handling so package transactions evicted by `LimitMempoolSize()` immediately after acceptance return `TX_RECONSIDERABLE` with `FeeFailure` rather than `TX_MEMPOOL_POLICY`. This covers multi-transaction package submissions, transactions accepted individually earlier in the same call, and transactions already present in the mempool (including same-txid different-witness entries) that are subsequently trimmed. It also records the effective feerate and calculation inputs so package retry logic has the necessary context.

Problem: When a package is accepted at the bottom of the mempool and pushes it over its size limit, the package transactions are immediately evicted. Because they return `TX_MEMPOOL_POLICY` rather than `TX_RECONSIDERABLE`, the evicted transactions (such as the parent in a 1p1c package) enter peer reject filters and cannot be fetched or re-evaluated with higher-fee child bumps until a new block arrives.

Evidence of importance:

• Author description: 'In-master, if a package is entered into mempool at the lowerst chunk feerate, pushing the mempool oversize, this causes that transaction (package) to be trimmed immediately... but the returned validation result TX_MEMPOOL_POLICY precludes the now-evicted parent from being considered again (i.e. fetched / processed as package) until after another block is found.'
• Author description: 'Related to finding made by Loupe, and subsequently Red Team.'

Scope: Small validation logic change in `MemPoolAccept::AcceptPackage()` with unit test coverage in `txpackage_tests.cpp` and functional coverage in `p2p_opportunistic_1p1c.py`.

Risk of a mistake: medium (validation, mempool_policy). A mistake in package accept result classification or feerate tracking could bypass mempool reject filters or mishandle package eviction relay state.

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

• reviewer: initial review 2026-09-28

Crickets

no substantive comment either way

Thread notes: Initial record. No participants or comments other than the author. / Initial record: PR opened by instagibbs, no reviewers or comments from others yet.

Objections, suggestions, and questions: none recorded.

172 lines under test/bench/ci.

• src/test/txpackage_tests.cpp +110/-0
• test/functional/p2p_opportunistic_1p1c.py +61/-1
• src/validation.cpp +23/-6

The short text the ranking pass compares across PRs.

Updates package mempool acceptance so that transactions accepted and immediately evicted by mempool size limits return TX_RECONSIDERABLE instead of TX_MEMPOOL_POLICY. Previously, if a low-feerate package pushed the mempool over capacity and was trimmed, the parent entered peer reject filters, preventing subsequent higher-fee children from bumping it until the next block. The PR fixes this unneeded censorship across all trimmed package transactions by returning reconsiderable fee failure results. Author notes this was uncovered by Loupe and verified by Red Team.

P2 · bug fix

Package transactions evicted immediately upon acceptance due to `LimitMempoolSize()` return `TX_MEMPOOL_POLICY` instead of `TX_RECONSIDERABLE`, causing peer reject filters to reject subsequent higher-fee bumps until the next block. As the author notes, this bug was discovered by Loupe and Red Team, and fixing it restores proper reconsiderable status and package retry logic for 1p1c and multi-transaction packages under mempool pressure.

Membership: Modifies `MemPoolAccept::AcceptPackage()` in `src/validation.cpp` to adjust package acceptance, eviction handling, and reject reasons.

Factors: security/stability 1, bug 2, performance 0, user value 1, leverage 1