Cardano Updates

Signed-off-by: Akhil Repala <[email protected]>

Bumps [next](https://github.com/vercel/next.js) from 15.3.2 to 15.5.18.
- [Release notes](https://github.com/vercel/next.js/releases)
- [Changelog](https://github.com/vercel/next.js/blob/canary/release.js)
- [Commits](https://github.com/vercel/next.js/compare/v15.3.2...v15.5.18)

---
updated-dependencies:
- dependency-name: next
  dependency-version: 15.5.18
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>

* Add examples/ folder with bootcamp companion code

* Restructure smart contract lessons into Theory and Practical tracks

Replace the eight flat lessons with their updated versions under a Practical
group, add a 15-lesson Theory track before them, and give each track a course
overview landing page (Blockchain Theory, Hello Cardano). Wire both groups in
the sidebar and redirect the old lesson URLs to their new paths.

* Add Pyth oracle integration doc

Document Pyth Pro price feeds on Cardano and add the page to the Oracles
sidebar. Drop the now-redundant Related footers from charli3 and orcfax.

* Fix broken link in the governance lesson

Point the end-of-course next step to the Hello Cardano overview instead of the
old curriculum path.

* Fix broken link in the token registry docs

Link the Token Registry Server page via its .md file so it resolves from the
question-named page, instead of nesting under it.

* Credit Cardano Builders and point the wallet link to cardano.org/apps

Add a one-line attribution to the Theory and Practical course overviews, and
swap the multisig lesson's old developer-showcase wallet link for the CIP30
wallet filter on cardano.org/apps.

Signed-off-by: Akhil Repala <[email protected]>

Bumps the pinned tag to include the runTracerA INLINE fix.

Without INLINE, every traceWith call with a nullTracer (Squelching
constructor) allocates a fresh Kleisli wrapper via arr (const ()).  In
the network-mux bearer hot path this amounts to 5 such calls per SDU.
With messages chunked into 1260-byte SDUs, a single 3 MB payload
generates thousands of SDUs and therefore thousands of spurious Kleisli
allocations per traceWith call, producing hundreds of MB of short-lived
GC pressure that pushes the test suite past the 900 MB Hydra limit.

With INLINE on runTracerA and the existing INLINE on traceWith, GHC
reduces traceWith nullTracer x to pure () at the call site: zero
allocation, no GC overhead.

HydraBudgetVote gated the vote UI on `multisigWallet.getDRepId()` being
truthy, but that is a local key/script derivation that always succeeds —
it is NOT proof of on-chain registration. So a wallet that is a fully
registered, active DRep (shown correctly by the DRep Information card)
was still told to "Register this wallet as a DRep first."

Detect registration the same way the DRep Information card does: look up
the DRep on-chain and check `active === true`. Done via a React Query
hit to Blockfrost `/governance/dreps/{cip105}` (the same endpoint and
getDRepIds helper the global wallet-data loader uses), which also gives a
clean loading state so we no longer flash "register first" before the
status is known. While the wallet or registration lookup is resolving we
show "Checking DRep registration…" instead of the register prompt.

Co-authored-by: Claude Fable 5 <[email protected]>

HydraBudgetVote gated the vote UI on `multisigWallet.getDRepId()` being
truthy, but that is a local key/script derivation that always succeeds —
it is NOT proof of on-chain registration. So a wallet that is a fully
registered, active DRep (shown correctly by the DRep Information card)
was still told to "Register this wallet as a DRep first."

Detect registration the same way the DRep Information card does: look up
the DRep on-chain and check `active === true`. Done via a React Query
hit to Blockfrost `/governance/dreps/{cip105}` (the same endpoint and
getDRepIds helper the global wallet-data loader uses), which also gives a
clean loading state so we no longer flash "register first" before the
status is known. While the wallet or registration lookup is resolving we
show "Checking DRep registration…" instead of the register prompt.

Co-Authored-By: Claude Fable 5 <[email protected]>

* fix(auth): use Mesh 1.9 wallet so signData args aren't swapped (VESPR -2)

WalletAuthModal signed the nonce with react-2.0's useWallet().wallet, a
low-level CIP-30 wallet whose signData(address, payload) argument order
is swapped relative to Mesh 1.9's signData(payload, address). The call
signData(nonce, address) therefore passed the nonce as the *address* and
the address as the *payload*, so VESPR tried to sign with a bogus signing
address and returned CIP-30 InternalError {code: -2}. (It also explains
the wallet dialog showing the address as the "Nachricht".)

Switch to the 1.9 BrowserWallet via useMeshWallet — the same instance and
(payload, address) order every other signing flow in the app uses. The
UTXOS MeshWallet path is also payload-first, so the single
signData(nonce, address) call is now correct for both wallet types.

Co-Authored-By: Claude Fable 5 <[email protected]>

* refactor(wallet): route all wallet ops through the Mesh 1.9 bridge + guardrail

Every signing/wallet call must use useMeshWallet()/useActiveWallet() (the
Mesh 1.9 IWallet), never react-2.0's useWallet().wallet — the latter is a
low-level CIP-30 wallet whose signData(address, payload) / signTx(tx,
partialSign) signatures differ from 1.9, so a wrong-order call compiles
but signs the wrong bytes.

Fixes 3 live latent copies of that bug (same root cause as the WalletAuth
modal fix):
- HydraBudgetVote: signData on the react-2.0 wallet — the likely source of
  the ballot witness/body-hash divergence.
- instance-tab (cross-instance import): would fail with CIP-30 -2 on VESPR.
- api-docs bearer-token generation: same swapped-args failure.

Also migrates the remaining read-only useWallet().wallet sites (address /
network-id lookups, identical across versions) to the bridge so the
boundary is uniform, and adds null guards where the bridge wallet is
transiently null while enabling.

Guardrail: an ESLint no-restricted-syntax rule makes destructuring
`wallet` from useWallet() a build error, so this bug class can't regress.
useWallet() stays allowed for connection state (name/connected/connect/
disconnect). Verified the rule fires on a violation and passes the bridge.

Co-Authored-By: Claude Fable 5 <[email protected]>

---------

Co-authored-by: Claude Fable 5 <[email protected]>

chore: release 1.0.0-rc.1