Co-authored-by: nullun <git@nullun.com>

Co-authored-by: nullun <git@nullun.com>

**S7.** The S6 fix mirrored `_assert_group_is_clean` into the browser, and the
mirror was faithful and insufficient. That guard checks hygiene - rekey, close,
group fee - and hygiene is not what a hostile conversion violates. A plain
asset transfer of the whole balance to a stranger carries no close, no rekey
and an ordinary fee, and passed the mirror completely.

The contract does not check `aamt` or `arcv` either, and does not need to: on a
routed group the rest of it checks - the input proven spent, the co-signed
floor, the pinned pools - and none of that runs unless the router is called. So
the mirror had copied the cheap outer shell and left out the part doing the
work. The two exempt entry points say the same thing from the other side:
`pool_budget` and `verify_discount` skip the hygiene guard precisely because
they ride alongside a route, so hygiene alone was never the safety argument.

`routedGroupProblems` now also requires a call to the router whose ARC-4
selector is not one of those two - "calls the router" would have passed
`[pool_budget, transfer-to-attacker]`, which calls the router and is checked by
nothing. The app id comes from `data-router-app`, handed down by the view and
overridable by a setting, with the same number in the widget as a fallback so a
missing attribute cannot switch the rule off. Not from the plan response: an id
the engine supplied would make the check agree with whatever the engine wanted,
which is S2 for the third time. The two excluded selectors are recomputed from
the method signatures by verify-sweep.sh rather than trusted as constants.

All four router groups in the audit's evidence carry non-exempt selectors, so
the rule accepts every conversion that has actually executed.

It also caught a test that had gone quiet. "Accepting implies no transaction
closes or rekeys" became vacuous the moment this landed - no corpus transaction
is an application call, so every generated group was refused for that reason
and the implication was never exercised. It now prefixes a real route call and
asserts that something really was accepted.

**S2 recommendation 2.** The row showed unit, id, badge, value and reason and
never the address the tokens went to, so on the one disposition that gives
something away the destination was the single fact the reader was not shown.
`destinationLabel` is the pure half, tested; `renderLine` only appends it. A
close says plainly that nothing leaves, because a blank cell there reads as a
missing fact rather than as reassurance. The audit is explicit that this
complements the chain lookup rather than replacing it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XqeQenXa9oWnLCWEvuiy8B

`signAction` decided whether to inspect a group by reading `action.kind` out
of the same response that carried the bytes. Every honest conversion carries a
router call the contract checks - but an assertion inside an application only
runs if the application is called, so a group labelled `convert` with no
application call in it was refused by nobody: not by this file, which returned
early, and not by `_assert_group_is_clean`, which was never in the group to
object. S2 was a reference value the engine supplied; this was the switch
deciding whether any checking happened.

`routedGroupProblems` mirrors that guard where it always runs - no rekey, no
close, no aclose, and the group's fee total against the contract's own
MAX_GROUP_FEE rather than a number picked here. Mirroring cannot refuse a group
the contract would accept.

The decoder risk this raised is settled with evidence rather than reasoning.
The seven groups in the audit's evidence/ were re-encoded from what the indexer
returned and run through the shipped decodeMsgpack: 97 of 97 decode,
application calls included, using only tags already supported. They are now a
fixture, so the accepting side of this rule is tested against traffic that
executed on mainnet instead of fixtures written to pass - and the ceiling has
fourteen times the headroom it needs, the dearest real group paying 71,000
against 1,000,000.

Writing it found something. "A conversion goes through the quote-signed path"
passed [CLOSE_TO_SELF] as its group, a stand-in chosen because the path did not
look at it. The new rule looked and refused it, correctly. That test now uses a
real convert group.

CREATOR_LOOKUP_TIMEOUT closes the one failure on the S2 path that neither
refused nor accepted: algosdk v3 sets no timeout, so a node that never answered
left the reader on a spinner with no prompt and no error. Ten seconds, then
null, which is the refusal the unreachable node already produced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XqeQenXa9oWnLCWEvuiy8B

The S2 fix rests on an invariant that spans two functions: a transaction may
close somewhere other than the sweeper's own account only when the plan calls
the holding a forfeit, and that same condition is what sends the destination
to the chain to be confirmed. Both spelled `Number(x.amount) !== 0` out
separately, so nothing failed if one of them changed - `closeOutProblems`
would keep accepting a forfeit that `forfeitTargetProblems` had quietly
stopped looking up. That is S2 reopening with a green suite.

`isForfeit` is now the single predicate, sitting beside `planLines`: that one
decides which lines are readable, this one decides what a readable line means.
A test crosses both halves over the amount shapes an engine can actually send.
Mutating one side to `> 0` fails three of them; before, it failed nothing.

The lookups also move into one `Promise.all` over the distinct asset ids,
decoding once up front. A group of sixteen forfeits waited sixteen times the
node's latency before the wallet prompt opened, because the await sat in the
compare loop. The rejection-to-null fold moved with it, so "could not be
confirmed" is still the single refusal path. The compare loop becoming a `.map`
is why the group side now gets the shape guard the `described` side has had
since `planLines`.

Three docstrings had drifted from the code and are corrected rather than left
to mislead the next reader of a security control: the fee is bounded per
transaction only, and `summaryFigures` reports the planner's figures without
verifying them - a planner reporting zero fees renders "0.00 ALGO"
unchallenged, and what bounds the loss is MAX_CLOSE_OUT_FEE on the bytes being
signed. `recoverable` genuinely is net of fees; the planner subtracts them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XqeQenXa9oWnLCWEvuiy8B

Adds a custom Vault secrets engine that manages Algorand post-quantum
(Falcon-1024) accounts, which the transit engine cannot do natively.

The plugin derives a Falcon-1024 keypair deterministically from 32 bytes of
entropy (the 25-word mnemonic) and stores the entropy, the canonical address
salt and the key material in the mount's barrier-encrypted storage — a PQ
account needs more than the mnemonic, since one public key can derive up to
256 addresses depending on the salt. Derivation follows go-algorand exactly
(SHA512-256 "PQK"/"PQA" domain separation, off-curve salt scan) and is pinned
by the official algokey test vector.

The API mirrors transit so the service can reuse its existing call patterns:
POST keys/{name} creates (idempotent), GET keys/{name} returns scheme, salt,
public key and address, POST sign/{name} signs base64 input, LIST keys
enumerates. Deletion, rotation, versioning and export are deliberately absent.

Wiring: scripts/build_vault_plugin.sh builds a static musl binary into the
plugin directory the vault container now mounts, and development-init
registers it by sha256, mounts it at pawn/pq-users and extends the AppRole
policies (users create, managers create/list/sign). CI builds the plugin
before the stack starts and runs the Go tests under the race detector.

The plugin is pinned to Go 1.23 because Vault 1.15 injects
GODEBUG=x509sha1=1 into the plugin processes it spawns and Go removed that
setting in 1.24; a newer toolchain aborts before the go-plugin handshake.

Go tests cover derivation against the official algokey vector, persistence
across a fresh backend instance and concurrent creates. The e2e suite adds a
block that talks to the mount directly — no service endpoint exposes PQ
accounts yet — re-deriving the returned address independently in TypeScript
and asserting the user AppRole can create but not sign.

Bumps [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin) from 8.69.0 to 8.68.0.
- [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases)
- [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/CHANGELOG.md)
- [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.68.0/packages/eslint-plugin)

---
updated-dependencies:
- dependency-name: "@typescript-eslint/eslint-plugin"
  dependency-version: 8.68.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>