* feat: show account name in ARC-14 auth prompt, auto-send after signing

Closes #170

- Authenticate button/label now reads "Authenticate to {realm} with
  {account}" when the signing account has a name, instead of just
  "Authenticate to {realm}".
- ARC-14 auth requests are never broadcast to the chain (they only
  produce a login signature), so there's no decision left for the
  user after signing - clicking Authenticate now signs and relays the
  result to the dApp in the same step, instead of waiting for a
  separate "Send back to DApp" click.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix: guard ARC-14 auto-send against mixed/partial requests

Code review on #171 found that the ARC14 auto-send comment's
assumption ("a request containing an ARC14 auth txn is always exactly
that single transaction") is not actually enforced anywhere - a dApp
can legally bundle an ungrouped auth transaction alongside ordinary
payment/asset transactions in the same request. Signing the auth
transaction first (e.g. via "Sign all") would previously trigger
sendResult while the other transactions were still unsigned, sending
the dApp a response with null placeholders and deleting the request
before the remaining transactions could be signed.

- clickSign now takes the parent RequestItem explicitly instead of
  re-deriving it by searching all pending requests for a matching
  txID (which could also resolve to the wrong request if two pending
  requests happened to contain byte-identical transactions).
- Auto-accept only fires once the whole request consists of nothing
  but ARC14 auth transactions and all of them are signed
  (isArc14OnlyRequest + allTransactionsSigned).
- clickAccept now guards against being dispatched twice for the same
  request id, since WalletConnect/Liquid Auth's sendResult is a
  one-shot response and a second call would throw or no-op
  inconsistently.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix: account for multisig threshold in ARC-14 auto-send gate

Further code review on #171: allTransactionsSigned() was checking
plain membership in signer.signed, but a multisig transaction is
added there as soon as the first of N required co-signatures is
present (see signer.ts's setSigned), not once the threshold is met.
For an ARC14-only request mixing a multisig-sender auth txn with a
regular one, this could auto-accept and relay an under-signed
multisig transaction to the dApp as soon as the other txn was signed.

Reuses the existing toBeSigned() helper, which already decodes msig
subsig counts against the threshold, instead of re-deriving a weaker
check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix: guard reject against racing an in-flight ARC-14 auto-accept

Further code review on #171: the ARC14 auto-accept path (sendResult)
can be in flight (awaiting a network round-trip to the dApp) while the
Reject button remains clickable, since it was only gated on
wallet.isOpen. Clicking Reject at that point would dispatch a second,
conflicting terminal response (cancelRequest) for the same request id
to the same dApp.

Renamed the existing accept-vs-accept re-entrancy guard to cover
reject-vs-accept too, so whichever of sendResult/cancelRequest starts
first for a given request id wins and the other silently no-ops,
matching the existing no-toast convention for the accept-side guard.

Also added a clarifying comment on arc14AuthenticateLabel's account-name
fallback: an account matched by address but with a blank name
intentionally falls back to the plain realm-only label (showing
"with " followed by nothing would look broken), so this isn't a bug
to fix even though a reviewer flagged the falsy check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix: surface an error toast when rejecting a request fails

clickReject was restructured with try/finally to add the
respondingRequestIds guard but had no catch, unlike clickAccept,
so a failed cancelRequest dispatch (e.g. a WalletConnect transport
error) surfaced no feedback - the user would believe their reject
went through. Mirrors clickAccept's existing error-toast handling.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Ludovit Scholtz <ludovit.scholtz@aaaauto.cz>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

clickReject was restructured with try/finally to add the
respondingRequestIds guard but had no catch, unlike clickAccept,
so a failed cancelRequest dispatch (e.g. a WalletConnect transport
error) surfaced no feedback - the user would believe their reject
went through. Mirrors clickAccept's existing error-toast handling.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Further code review on #171: the ARC14 auto-accept path (sendResult)
can be in flight (awaiting a network round-trip to the dApp) while the
Reject button remains clickable, since it was only gated on
wallet.isOpen. Clicking Reject at that point would dispatch a second,
conflicting terminal response (cancelRequest) for the same request id
to the same dApp.

Renamed the existing accept-vs-accept re-entrancy guard to cover
reject-vs-accept too, so whichever of sendResult/cancelRequest starts
first for a given request id wins and the other silently no-ops,
matching the existing no-toast convention for the accept-side guard.

Also added a clarifying comment on arc14AuthenticateLabel's account-name
fallback: an account matched by address but with a blank name
intentionally falls back to the plain realm-only label (showing
"with " followed by nothing would look broken), so this isn't a bug
to fix even though a reviewer flagged the falsy check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Further code review on #171: allTransactionsSigned() was checking
plain membership in signer.signed, but a multisig transaction is
added there as soon as the first of N required co-signatures is
present (see signer.ts's setSigned), not once the threshold is met.
For an ARC14-only request mixing a multisig-sender auth txn with a
regular one, this could auto-accept and relay an under-signed
multisig transaction to the dApp as soon as the other txn was signed.

Reuses the existing toBeSigned() helper, which already decodes msig
subsig counts against the threshold, instead of re-deriving a weaker
check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

--follow substituted a backlog of 10 when --lines was not given, so -n
meant one thing alone and another beside -f: `-n 0 -f` replayed the
whole history, where `tail -n 0 -f` shows none of it. --follow now
replays the same set the command shows without it, --lines N shortens
that backlog, and a stream that starts at now is --since 0s.

The cost is that a bare -f reads the whole history before the first
new entry arrives, as the command without -f already does.

Code review on #171 found that the ARC14 auto-send comment's
assumption ("a request containing an ARC14 auth txn is always exactly
that single transaction") is not actually enforced anywhere - a dApp
can legally bundle an ungrouped auth transaction alongside ordinary
payment/asset transactions in the same request. Signing the auth
transaction first (e.g. via "Sign all") would previously trigger
sendResult while the other transactions were still unsigned, sending
the dApp a response with null placeholders and deleting the request
before the remaining transactions could be signed.

- clickSign now takes the parent RequestItem explicitly instead of
  re-deriving it by searching all pending requests for a matching
  txID (which could also resolve to the wrong request if two pending
  requests happened to contain byte-identical transactions).
- Auto-accept only fires once the whole request consists of nothing
  but ARC14 auth transactions and all of them are signed
  (isArc14OnlyRequest + allTransactionsSigned).
- clickAccept now guards against being dispatched twice for the same
  request id, since WalletConnect/Liquid Auth's sendResult is a
  one-shot response and a second call would throw or no-op
  inconsistently.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Both genesis downloads reached for a package-level client, so a test had
no way to point them at a mock server. Take an api.HttpPkgInterface like
the release checks, the catchpoint lookup and the short links already do.
GetGenesis has no callers; handleDataDirMac gets the client from
algod.Install, which the install and bootstrap commands now supply.

Drop main_test.go with it. A test binary is not linked as package main,
so the linker never stamps main.version there and both sides of the
comparison were the same "dev" default: the test passed whether or not
init handed the version over. api/useragent_test.go covers SetVersion.