chore: promote dev to canary

[iap]

Summary

Promotes dev to canary — 56 commits since the last promotion.

Key changes

• feat(contracts): EIP-712 migration for AttestedSettlementVerifier
• fix: remove chainId double-encoding from EIP-712 struct
• feat(token): rename RYLA display name to 'RYLA Credits'
• test(contracts): bridge integration test + bridge invariant fuzz tests (74 total)
• fix(ci): workflow timeouts, check name accuracy, governance ruleset fixes
• docs(contracts): trust model section in RUNBOOK.md
• chore(deps): TypeScript 6, @types/node 25, frontend updates
• chore: SECURITY.md, gitignore, stale docs removed

Verification

forge test: 74 tests passed, 0 failed

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 6 package(s) with unknown licenses.
• ⚠️ 4 packages with OpenSSF Scorecard issues.

View full job summary

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 64d49a178e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

mark/scripts/github/apply-governance.sh

Lines 43 to 44 in 4d2fcee

	if [[ "$remote" =~ ^git@github.com:([^/]+/[^/]+)(\.git)?$ ]]; then
	echo "${BASH_REMATCH[1]}"

Strip .git when inferring GH_REPO from origin

The origin parser captures owner/repo.git into BASH_REMATCH[1] for standard remote URLs ending in .git (for example git@github.com:org/repo.git), so GH_REPO becomes org/repo.git. That value is then split into owner/repo and used for API calls like /repos/${owner}/${repo}/branches/..., which targets .../repos/org/repo.git/... and typically 404s, causing governance application to fail unless callers manually override GH_REPO.

---

mark/.github/workflows/release-evidence-validator.yml

Line 42 in 4d2fcee

"Environment used: `production`",

Parse environment field in the same shape as template

The validator treats Environment used: production`` as a key-value field by appending : in `getFieldValue`, but the release template defines it as a fixed line without a trailing colon (`.github/PULL_REQUEST_TEMPLATE/release.md` line 51). As a result, release PRs created from the template will always fail with `Missing field line: "Environment used: `production`:"` unless authors manually rewrite that line, blocking the required `Validate Release Evidence` check on `main`.

---

mark/.github/workflows/release-pr-checklist.yml

Line 55 in 4d2fcee

if [[ "$go_checked" -eq 0 && "$nogo_checked" -eq 0 ]]; then

Reject contradictory Go and No-Go selections

The checklist gate only fails when neither option is checked, so a PR with both - [x] Go and - [x] No-Go (reason) passes validation. That allows the required Validate Release PR Checklist check to succeed despite an explicitly contradictory release decision, which weakens the final release approval control.

---

mark/.github/workflows/release-evidence-validator.yml

Line 42 in 4d2fcee

"Environment used: `production`",

Parse production environment line without appended colon

The validator parses fields with ^- <label>: ...$, but the release template defines Environment used: production`` as a fixed line without a trailing colon (.github/PULL_REQUEST_TEMPLATE/release.md line 51). This makes `getFieldValue("Environment used: `production`")` return null for template-based PRs, so the required `Validate Release Evidence` check fails unless authors manually rewrite that line.

---

mark/.github/workflows/release-pr-checklist.yml

Line 55 in 4d2fcee

if [[ "$go_checked" -eq 0 && "$nogo_checked" -eq 0 ]]; then

Reject simultaneous Go and No-Go selections

The checklist gate only errors when both options are unchecked, so a PR that marks both Go and No-Go (reason) still passes this required workflow. That allows contradictory release decisions to clear the governance check instead of forcing a single explicit outcome.

---

mark/.github/workflows/release-pr-checklist.yml

Lines 38 to 43 in 4d2fcee

	require_checked '`Contracts Unit + Invariant` CI passed'
	require_checked '`Contracts Release Check (Dry-Run + Execute Smoke)` CI passed'
	require_checked '`Slither Core Contracts` CI passed'
	require_checked '`Contracts Mainnet Readiness` run from `main` branch'
	require_checked 'Readiness artifact uploaded and reviewed'
	require_checked 'Verify output reviewed (role/config expectations)'

Enforce all required evidence checkboxes

This validator checks only a subset of the template’s “Required Evidence” items, omitting entries like Contracts Production Mode Smoke, Analyze (javascript-typescript), Gitleaks Scan, Dependency Review, and both frontend checks. As a result, Validate Release PR Checklist can pass even when multiple fields explicitly marked required in .github/PULL_REQUEST_TEMPLATE/release.md are left unchecked.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Validate dev stale-review setting against applied baseline

Verification skips dismiss_stale_reviews for dev (check_branch dev false), but the baseline applied by scripts/github/apply-governance.sh sets dismiss_stale_reviews: true for all protected branches. This mismatch creates a false pass condition where drift on dev stale-review enforcement is not detected by governance verification.

Useful? React with 👍 / 👎.