Updates the requirements on [eslint-plugin-vue](https://github.com/vuejs/eslint-plugin-vue) to permit the latest version.
- [Release notes](https://github.com/vuejs/eslint-plugin-vue/releases)
- [Changelog](https://github.com/vuejs/eslint-plugin-vue/blob/master/CHANGELOG.md)
- [Commits](https://github.com/vuejs/eslint-plugin-vue/compare/v10.11.0...v10.11.1)

---
updated-dependencies:
- dependency-name: eslint-plugin-vue
  dependency-version: 10.11.1
  dependency-type: direct:development
...

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

Updates the requirements on [eslint](https://github.com/eslint/eslint) to permit the latest version.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Commits](https://github.com/eslint/eslint/compare/v10.9.1...v10.11.0)

---
updated-dependencies:
- dependency-name: eslint
  dependency-version: 10.11.0
  dependency-type: direct:development
...

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

Updates the requirements on [algosdk](https://github.com/algorand/js-algorand-sdk) to permit the latest version.
- [Release notes](https://github.com/algorand/js-algorand-sdk/releases)
- [Changelog](https://github.com/algorand/js-algorand-sdk/blob/main/CHANGELOG.md)
- [Commits](https://github.com/algorand/js-algorand-sdk/compare/v3.7.0...v3.8.0)

---
updated-dependencies:
- dependency-name: algosdk
  dependency-version: 3.8.0
  dependency-type: direct:production
...

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

Updates the requirements on [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/parser) to permit the latest version.
- [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases)
- [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/CHANGELOG.md)
- [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.70.1/packages/parser)

---
updated-dependencies:
- dependency-name: "@typescript-eslint/parser"
  dependency-version: 8.70.1
  dependency-type: direct:development
...

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

* feat: show ARC-56 registry summary and GitHub publisher warnings

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>

* fix: address code review findings on ARC-56 summary PR

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>

* fix: stuck spinner and stale trust-signal caching

Further code review on #172:

- Arc56RequestSummary.vue's early return for a request with no app
  calls never reset `loading`, and a still-in-flight older runDecode()
  call's own finally also skips it (generation mismatch) - left the
  spinner stuck on forever if the transaction set changed to one with
  no app calls while a previous decode was still resolving.
- algod/getApplicationPrograms's new cache never expired successful
  lookups, so a legitimate application-update transaction mid-session
  (changing an app's approval program) would never be picked up - the
  ARC-56 trust/publisher summary could keep showing a stale "verified"
  result for code that's no longer actually deployed. Changed to only
  dedupe genuinely concurrent callers (delete the cache entry as soon
  as the request settles, in a finally), which still solves the
  original duplicate-fetch problem (summary + detail view expanding
  for the same app at once) without ever serving a stale trust signal
  to a later, separate caller.

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

* fix: getApplicationPrograms must not throw synchronously on bad config

Code review on #172: building the cache key required reading
getAlgodConfig(rootState) before the async IIFE, but that call throws
synchronously if algod/algodToken isn't configured - contradicting the
action's own documented "returns undefined rather than throwing"
contract. Existing call sites happen to wrap the dispatch in
try/await, so this wasn't reachable as a crash today, but a caller
using .catch() chaining instead would never get the chance to attach
it. Now caught explicitly and resolves to undefined like every other
failure path in this action.

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

* fix: per-entry failure isolation, dedup decode logic, safer cache key/txID

Further code review on #172:

- Arc56RequestSummary.vue wrapped every app call's decode in a single
  Promise.all - one entry's rejection wiped the trust/publisher
  summary for the whole request instead of degrading only that entry.
  Switched to Promise.allSettled with per-result error handling.
- Extracted the shared "buildAppCallInfo -> decodeArc56AppCall ->
  fetch owners" sequence (duplicated between Arc56CallDetails.vue and
  Arc56RequestSummary.vue, and the source of two previous review
  rounds' bugs) into decodeAppCallWithOwners() in decode.ts, used by
  both. Only the Vue/store-specific algod dispatch stays per-component.
- Consolidated arc56TrustSeverity/TitleKey/DescKey's three independent
  switch statements (each with its own `default` fallback, so a future
  Arc56TrustLevel value could update one and silently miss another)
  into a single Record<Arc56TrustLevel, ...> lookup, which TypeScript
  itself now enforces stays exhaustive.
- getApplicationPrograms's in-flight dedup cache key omitted
  algodToken, so two configs sharing the same algod URL but different
  auth tokens would incorrectly dedupe onto each other's response.
- The txID()-based watch keys in both components called algosdk's
  txID() unguarded - it can throw for a malformed transaction, and
  since it ran inside a watch getter, Vue would silently swallow the
  throw and the watcher would simply never fire again (no visible
  error, no decode, no warning). Added decode.ts's safeTxId() and used
  it in both.

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

* fix: Badge severity doesn't accept "error" - it needs "danger"

Code review on #172 found that arc56TrustSeverity()'s "error" value
(used for the verified-other-method trust level - "more suspicious
than unknown, not less" per decode.ts's own top comment) is valid for
PrimeVue <Message> but not <Badge>, whose severity enum has "danger"
instead of "error" and no "error" at all - an actual inconsistency
between the two PrimeVue components, not a typo on either side. The
multi-app-call summary table's <Badge> was silently losing this exact
signal (rendering unstyled instead of red) for the one trust level
that's arguably the most alarming, in the multi-transaction case where
a user is least likely to expand every row to check.

Added arc56TrustBadgeSeverity() as the <Badge>-safe converter and
switched the summary table to it; <Message> usages (the single-app
card, and Arc56CallDetails.vue's own top-level severity) keep using
arc56TrustSeverity() unchanged, since "error" is correct there.

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

* fix: cache-delete/set ordering bug on synchronous algod-client failure

Code review on #172: if createAlgodClient() throws synchronously (e.g.
new URL(algod) on a malformed custom node URL), the async IIFE's whole
try/catch/finally runs synchronously before the outer
applicationProgramsCache.set(cacheKey, promise) call ever executes -
so the finally's delete(cacheKey) is a no-op on a key that isn't in
the map yet, and the subsequent .set() then permanently caches the
failed (undefined) result, contradicting this cache's whole point
(dedupe concurrent callers only, never serve a stale/failed result to
a later separate caller).

Fixed by yielding to a microtask (`await Promise.resolve()`) as the
first line of the IIFE, forcing every synchronous throw inside it to
happen after the outer .set() call has already run. Verified the
ordering bug and the fix with a standalone repro before applying it
here.

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>

Code review on #172: if createAlgodClient() throws synchronously (e.g.
new URL(algod) on a malformed custom node URL), the async IIFE's whole
try/catch/finally runs synchronously before the outer
applicationProgramsCache.set(cacheKey, promise) call ever executes -
so the finally's delete(cacheKey) is a no-op on a key that isn't in
the map yet, and the subsequent .set() then permanently caches the
failed (undefined) result, contradicting this cache's whole point
(dedupe concurrent callers only, never serve a stale/failed result to
a later separate caller).

Fixed by yielding to a microtask (`await Promise.resolve()`) as the
first line of the IIFE, forcing every synchronous throw inside it to
happen after the outer .set() call has already run. Verified the
ordering bug and the fix with a standalone repro before applying it
here.

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

Code review on #172 found that arc56TrustSeverity()'s "error" value
(used for the verified-other-method trust level - "more suspicious
than unknown, not less" per decode.ts's own top comment) is valid for
PrimeVue <Message> but not <Badge>, whose severity enum has "danger"
instead of "error" and no "error" at all - an actual inconsistency
between the two PrimeVue components, not a typo on either side. The
multi-app-call summary table's <Badge> was silently losing this exact
signal (rendering unstyled instead of red) for the one trust level
that's arguably the most alarming, in the multi-transaction case where
a user is least likely to expand every row to check.

Added arc56TrustBadgeSeverity() as the <Badge>-safe converter and
switched the summary table to it; <Message> usages (the single-app
card, and Arc56CallDetails.vue's own top-level severity) keep using
arc56TrustSeverity() unchanged, since "error" is correct there.

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

Further code review on #172:

- Arc56RequestSummary.vue wrapped every app call's decode in a single
  Promise.all - one entry's rejection wiped the trust/publisher
  summary for the whole request instead of degrading only that entry.
  Switched to Promise.allSettled with per-result error handling.
- Extracted the shared "buildAppCallInfo -> decodeArc56AppCall ->
  fetch owners" sequence (duplicated between Arc56CallDetails.vue and
  Arc56RequestSummary.vue, and the source of two previous review
  rounds' bugs) into decodeAppCallWithOwners() in decode.ts, used by
  both. Only the Vue/store-specific algod dispatch stays per-component.
- Consolidated arc56TrustSeverity/TitleKey/DescKey's three independent
  switch statements (each with its own `default` fallback, so a future
  Arc56TrustLevel value could update one and silently miss another)
  into a single Record<Arc56TrustLevel, ...> lookup, which TypeScript
  itself now enforces stays exhaustive.
- getApplicationPrograms's in-flight dedup cache key omitted
  algodToken, so two configs sharing the same algod URL but different
  auth tokens would incorrectly dedupe onto each other's response.
- The txID()-based watch keys in both components called algosdk's
  txID() unguarded - it can throw for a malformed transaction, and
  since it ran inside a watch getter, Vue would silently swallow the
  throw and the watcher would simply never fire again (no visible
  error, no decode, no warning). Added decode.ts's safeTxId() and used
  it in both.

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

Code review on #172: building the cache key required reading
getAlgodConfig(rootState) before the async IIFE, but that call throws
synchronously if algod/algodToken isn't configured - contradicting the
action's own documented "returns undefined rather than throwing"
contract. Existing call sites happen to wrap the dispatch in
try/await, so this wasn't reachable as a crash today, but a caller
using .catch() chaining instead would never get the chance to attach
it. Now caught explicitly and resolves to undefined like every other
failure path in this action.

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

Further code review on #172:

- Arc56RequestSummary.vue's early return for a request with no app
  calls never reset `loading`, and a still-in-flight older runDecode()
  call's own finally also skips it (generation mismatch) - left the
  spinner stuck on forever if the transaction set changed to one with
  no app calls while a previous decode was still resolving.
- algod/getApplicationPrograms's new cache never expired successful
  lookups, so a legitimate application-update transaction mid-session
  (changing an app's approval program) would never be picked up - the
  ARC-56 trust/publisher summary could keep showing a stale "verified"
  result for code that's no longer actually deployed. Changed to only
  dedupe genuinely concurrent callers (delete the cache entry as soon
  as the request settles, in a finally), which still solves the
  original duplicate-fetch problem (summary + detail view expanding
  for the same app at once) without ever serving a stale trust signal
  to a later, separate caller.

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