Multiple review passes on #172 found real issues:

- Arc56RequestSummary.vue used a plain falsy check on an app-creation
  call's appIndex (0), silently dropping such transactions from the
  aggregated summary entirely - fixed to check `=== undefined`.
- Arc56RequestSummary.vue collapsed "not looked up" (no approvalHash)
  and "looked up, no publisher" into the same `[]`, showing a false
  "no known publisher" warning for calls that were never eligible for
  a hash lookup (e.g. trust "not-abi") - unlike Arc56CallDetails.vue's
  deliberate null/[] distinction. Both now share that distinction via
  the new Arc56OwnerLinks.vue component.
- Extracted the trust->severity/copy switch statements (duplicated
  verbatim between Arc56CallDetails.vue and Arc56RequestSummary.vue)
  into arc56TrustSeverity/TitleKey/DescKey in decode.ts, so a future
  Arc56TrustLevel value can't update one view's rendering while
  silently leaving the other on an incomplete switch.
- Extracted the 3x-duplicated GitHub-owner-links markup into
  Arc56OwnerLinks.vue.
- isSingleAppCall was a plain function re-invoked on every render;
  changed to a computed().
- Restored the app-call guard before dispatching to algod in
  Arc56CallDetails.vue (was reordered during the previous refactor,
  currently unreachable given both call sites gate on type=='appl',
  but latent otherwise).
- Added a generation-token guard against stale runDecode() results
  overwriting fresher ones in both components, and keyed
  Arc56CallDetails.vue's watch on txID instead of object identity
  (ConnectRequestsTable/SignAll rebuild their transaction arrays on
  every store update even when nothing actually changed).
- Added an in-memory cache to algod/getApplicationPrograms, keyed by
  endpoint+appIndex - the summary and detail views (and
  TransactionGroupSimulation) can all request the same app's programs
  for the same request, previously each a fresh algod round-trip.
- Wired Arc56RequestSummary into SignAll.vue too (raw/offline group
  signing), not just ConnectRequestsTable - the exact case where a
  spoofed/unverified app call matters most was previously uncovered.

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

Adds an application-call summary above the transaction table in
WalletConnect/Liquid Auth requests, so a user relying on "Sign all"
doesn't have to expand every app-call transaction to check its ARC-56
registry status:

- A request whose only transaction is an app call shows a full summary
  (trust level, contract name, method, and every GitHub owner/repo
  known to have published matching source) right above the table.
- A request with several app calls (alongside other transactions, or
  several app calls in one request) shows a compact per-app list with
  the same trust badge and publisher info, so warnings are visible
  without crawling through each transaction's expanded detail row.

Publisher info comes from the new approval-programs/clear-programs/
<hash>.owners.json files exposed by the companion ARC56Registry change
(scholtz/ARC56Registry#1): every GitHub owner/repo whose indexed spec
compiles to the app's program hash, not just the largest matching spec
- since a legitimate contract can be forked/vendored across several
repos, but an app with *no* known publisher at all is exactly the case
a scam is most likely to hide in.

- src/scripts/arc56/registry.ts: fetchArc56OwnersByProgramHash(), new
  Arc56Owner/Arc56OwnersEntry types.
- src/scripts/arc56/decode.ts: extracted encodeAddressSafe()/
  buildAppCallInfo() out of Arc56CallDetails.vue so the new summary
  component and the existing per-transaction detail view share the
  same address-encoding and preceding-group-txn logic instead of
  duplicating it.
- src/components/Arc56RequestSummary.vue: the new summary component.
- src/components/Arc56CallDetails.vue: also shows publisher info in
  the existing per-transaction detail view.

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

* 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>