Cardano Updates

Co-authored-by: sg-doc-holiday[bot] <219201796+sg-doc-holiday[bot]@users.noreply.github.com>

Signed-off-by: Chris Gianelloni <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

Add permissions block with contents: read, required by
actions/checkout to clone the repository.

Fixes https://github.com/IntersectMBO/cardano-updates/security/code-scanning/3

- fix float to int generated by toToml; Dolos requires int
- fix to not generate duplicate [genesis] key

Signed-off-by: Ales Verbic <[email protected]>

Add permissions block with contents: read, required by
actions/checkout to clone the repository.

Fixes https://github.com/IntersectMBO/cardano-updates/security/code-scanning/3

Add permissions block with contents: write, required by
peaceiris/actions-gh-pages to push build output to the gh-pages branch.

Fixes https://github.com/IntersectMBO/cardano-updates/security/code-scanning/4

# Conflicts:
#	modules/midnight_state/src/grpc/service.rs

The main goal of this PR is to extend the ChainDB API and implementation
with a new method that retrieves the latest (as in _highest_) round
number of a Peras certificate included in a block in our preferred
chain:

 ```haskell
getLatestPerasCertOnChainRound :: STM m (Maybe PerasRoundNo)
```

This is needed by an upcoming voting thread to evaluate the Peras voting rules at the beginning of each Peras round (modulo being also part of the voting committee). 

Worth mentioning, the reason this method only retrieves round numbers and not entire certificates is twofold:
* after certificates are validated, we no longer care about their contents other than their corresponding round numbers (which is ultimately only needed by one of the (sub-) voting rules), and
* round numbers are non-parametric (as opposed to certificates being parameterized by `blk`), substantially simplifying the implementation of this PR.
Nonetheless, it should be straightforward to extend this changes if in the future we find out that we need to extract more information from the latest certificate on chain.

The changes are divided into a couple of (hopefully digestible) atomic commits and I would suggest reviewing them in order:

- 1) Extending `BlockSupportsPeras` with a primitive to (possibly) extract certificates from blocks[^1].

- 2) Extend the Shelley ledger state with a field to cache the latest round number seen in a block. This value is updated whenever a new block is applied to the ledger.

- 3) Introducing the `LedgerSupportsPeras` type class to give access to this field from an arbitrary ledger state (notably needed by the hard fork ledger state), and propagating the constraint everywhere.

- 4) Extending the ChainDB API with the aforementioned `getLatestPerasCertOnChainRound` method, and providing an implementation that returns the latest round number between the ones found in the ledger state of both the volatile and immutable tips[^2].

- 5) (and vi.) Extending the `TestBlock` used by the storage tests to replicate the changes made by (ii) and (iii) to the Shelley ledger state.

- 7) Extending the ChainDB QSM model and tests to exercise the new method in the ChainDB API[^3].

Closes https://github.com/tweag/cardano-peras/issues/198

[^1]: this currently has a degenerate instance that always returns `Nothing`, but this will notably will not be the case after integrating the [changes](https://github.com/IntersectMBO/cardano-ledger/pull/5439) made to the Ledger layer to (possibly) include Peras certificates in Dijkstra block bodies.

[^2]: this might seem overly conservative at first but, as far as we can tell, there is no guarantee that a newer certificate (as in, one included in a younger block) will necessarily point to a higher Peras round number. This means that, the latest round number could be in a certificate included in an immutable block, even if there are newer certificates included in blocks in the volatile suffix. So, we always end up reaching for the maximum of all the available options.

[^3]: this notably required disabling the generation of the new command (as well as the inclusion of certificates in test blocks for good measure) whenever a test runs with `LoEEnabled`. Supporting both simultaneously is outside of the scope of this PR (and of pre-alpha Peras as whole).

* chore: bump cardano-js-sdk

* fix: register runtime.onConnect synchronously on SW startup

When the service worker is woken by a content script connection,
the runtime.onConnect listener was not yet registered because it
was set up lazily inside the dynamically imported modules. This
caused the first DApp connector call to fail.

Call getBackgroundMessenger synchronously before the dynamic import
so the listener is in place immediately. The singleton ensures all
later exposeApi calls reuse the same messenger instance.

Bumps [dompurify](https://github.com/cure53/DOMPurify) from 3.3.1 to 3.3.3.
- [Release notes](https://github.com/cure53/DOMPurify/releases)
- [Commits](https://github.com/cure53/DOMPurify/compare/3.3.1...3.3.3)

---
updated-dependencies:
- dependency-name: dompurify
  dependency-version: 3.3.3
  dependency-type: indirect
...

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

Wrap connectToLocalNode in try @SomeException and introduce a unified
TxSubmitResult return type with three constructors: TxSubmitSuccess,
TxSubmitFail, and TxSubmitError. Previously, network-level errors (e.g.
BearerClosed) escaped as exceptions; they are now surfaced as TxSubmitError.

Update the cardano-rpc call site to pattern-match on TxSubmitResult
directly, removing the tryAny workaround it used to compensate for this.

* Add group profile onboarding E2E: feature files, remote-initiator helper, ssi-agent-urls

* updated the helper, steps

* updated the test

* added contract

* test: split group profile features and backend step definitions

* chore(test): added createBackendUser and createRemoteInitiator interfaces

* chore: add support for witness config

* fixed getOObi, added agent role in init

* chore: eventual acceptGroupInvitation fix

* fix: Joiner business logic

* fix: add endRole sign from remoteJoiner aafter group creation

* test: normalize tests for Initiator creates multisig group and it becomes active

* test: fix the step "all members accept the group invitation"

* test(e2e): address PR comments

---------

Co-authored-by: Ankit Shukla <[email protected]>
Co-authored-by: Ankit Shukla <[email protected]>
Co-authored-by: Ankit Shukla <[email protected]>