requestRedeem accepts any nonzero share amount and processNext advances exactly one FIFO entry per call. A holder of a tiny share balance can submit many one-wei requests cheaply; every later request then needs that many extra processNext transactions (each with its own gas) before it can be priced and claimed.

For an untaxed asset the liquid redeem() path is an alternative, but for a receiver-taxed asset the exact-receipt redeem()/withdraw() paths revert (see testTaxedDepositExtensionAndOutput), so the queue is the only exit path and this becomes a griefing cost on every honest withdrawal. The analysis notes keeper availability as a liveness dependency but not that queue depth is attacker-controlled at near-zero cost.

Possible in-design mitigations: a minimum request size, or letting processNext take a bounded batch count.

The required deliverable docs/SUMMARY.md must give the number of tests per contract.

The tree now contains 212 tests (194 unit/fuzz plus 18 invariant suites) after the second commit added test extensions, but docs/SUMMARY.md still says 118 and its per-contract Tests column reflects the old files (e.g. LendingPool 12 vs 16 test functions now in test/LendingPool.t.sol plus one invariant; Vault4626 9 vs 13; StakingRewards 7 vs 11; Escrow 6 vs 10; TokenBridgeLock 5 vs 11). docs/SECURITY_REVIEW.md line 16 likewise states '118 tests in 19 suites' and line 7 pins Foundry 1.8.3 while the pinned toolchain here is 1.8.5.

The updated table exists only in test/SUMMARY.md and test/ANALYSIS.md, which are not the required locations and duplicate documentation inside the test directory. The analysis sections in docs/ANALYSIS.md also do not mention the invariant handlers that now exist for 18 contracts.

Timelock.execute is nonReentrant and onlyAdmin. A self-call can only originate from inside an outer execute, so an operation whose stored call is Timelock.execute(innerId) always hits ReentrancyGuardReentrantCall, the outer call reverts with CallFailed, and the inner operation is never marked done.

The code behaviour is safe and arguably desirable, but the documented role table lists execute among the powers of a scheduled self-call, which is wrong. queue, cancel and nominateAdmin via self-call do work as documented.

ERC-3156 lets any caller initiate a loan for a receiver; the receiver protects itself by checking the initiator argument in onFlashLoan. This implementation additionally requires receiver == msg.sender, so routers, aggregators or EOAs that initiate on behalf of a receiver contract cannot use it.

The restriction is deliberate and documented in ANALYSIS.md section 15 ('documented self-initiated borrower restriction'), and it closes the allowance-consumption vector, so this is a scope observation about standard conformance rather than a vulnerability. The spec line reads 'ERC-3156 flash loans'; whether strict interface conformance is required is a requester decision.

After deliver(), refundAt = now + 3 days and timeoutRefund() in the Delivered state credits the entire amount to the buyer. A buyer who receives the goods and simply does nothing is refunded; the seller's only protection is to call dispute() on its own delivery within the three-day window and then depend on the arbiter resolving within seven days (an unresolved dispute also refunds the buyer).

ANALYSIS.md section 10 documents this buyer-default rule explicitly, so it is reported as a design observation, not a defect: the spec's 'timeout refund' is satisfied, but a seller can never be paid without an action by the buyer or the arbiter. If the requester intends the usual auto-release-to-seller after an undisputed review window, that is a design change.

debtOf() grows every second once the position is large enough (about 1.3 base units per second for a 1000e6 six-decimal debt at 4% APR). An EOA that reads debtOf and submits repay(borrower, quoted) in a later block pays slightly less than the current debt, so _repay takes the partial branch and leaves a residual debt share.

The residual can be cleared with a second repay of exactly the remaining owed amount, so funds are not stuck and nothing is lost; this is a usability gap (most lending pools accept type(uint256).max as 'repay everything'). Partial dust repayments that round to zero shares revert with InvalidInput, which is correct but adds friction. No economic impact.