fix(ci): sync miner engine-version pin on the engine release branch

[JSONbored]

Summary

• The engine release-please branch (e.g. chore(release): cut engine v3.1.0 #5807, engine v3.1.0) fails test:engine-parity every time, because scripts/check-engine-parity.ts's checkMinerEngineVersionPinSync requires packages/loopover-miner/expected-engine.version to match packages/loopover-engine/package.json's version, but release-please's engine component only ever touches files under packages/loopover-engine/** — it has no way to update that cross-package pin.
• Extends the existing "sync package-lock.json on any release branch" step in mcp-release-please.yml to also write the pin file whenever the engine branch's version changes, reusing the same fetch/checkout/commit-if-changed pattern already used for the lockfile.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — maintainer PR fixing a CI defect discovered live on chore(release): cut engine v3.1.0 #5807, no linked issue.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck — skipped, no .ts/source files touched (workflow-YAML-only change).
• npm run test:coverage — skipped, src/** untouched, not covered by Codecov patch, no new branches introduced.
• npm run test:workers / npm run build:mcp / npm run test:mcp-pack / npm run ui:* — skipped, none of these are affected by a .github/workflows/**-only change.
• npm audit --audit-level=moderate — skipped, no dependency changes.
• New or changed behavior has unit/integration tests — the added bash step isn't unit-testable in isolation; validated by dry-running the equivalent node -p/printf/git diff --quiet logic locally against a scratch git repo before pushing.

If any required check was skipped, explain why:

• This is a .github/workflows/**-only change (no src/, test/, or dependency changes), so the JS/TS build, typecheck, coverage, and UI checks have no surface to exercise. actionlint (the workflow-syntax validator) passed, and the new bash block's version-read/write/diff logic was manually dry-run locally.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — N/A, no such changes.
• API/OpenAPI/MCP behavior is updated and tested where needed. — N/A, no API/OpenAPI/MCP changes.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. — N/A, no UI changes.
• Visible UI changes include a UI Evidence section. — N/A, no UI changes.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. — this PR does not touch CHANGELOG.md.

Notes

• Discovered while triaging why the engine release-please PR (chore(release): cut engine v3.1.0 #5807) had cascading validate-tests failures despite a clean merge state.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.11%. Comparing base (c602050) to head (615545d).
⚠️ Report is 7 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5856   +/-   ##
=======================================
  Coverage   95.11%   95.11%           
=======================================
  Files         587      587           
  Lines       46509    46509           
  Branches    14870    14870           
=======================================
  Hits        44238    44238           
  Misses       1515     1515           
  Partials      756      756           

Flag	Coverage Δ
shard-1	43.76% <ø> (ø)
shard-2	36.18% <ø> (ø)
shard-3	32.12% <ø> (ø)
shard-4	32.81% <ø> (ø)
shard-5	31.62% <ø> (ø)
shard-6	44.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-14 20:07:23 UTC}

1 file · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This adds a conditional block that writes packages/loopover-miner/expected-engine.version from the engine package's version whenever the engine release branch is touched, reusing the existing checkout/commit/push pattern already used for package-lock.json sync in the same job. The logic is correct: it runs only when component == "engine" after the loop's checkout of that branch, computes the version via the same node -p pattern already used elsewhere in the file (publish-engine.yml), and only commits/pushes if the file actually changed. This is a narrow, workflow-YAML-only CI fix with no source/schema changes, consistent with the stated intent of unblocking test:engine-parity on release-please engine branches.

Nits — 3 non-blocking

• The PR checklist admits no linked issue (maintainer PR citing chore(release): cut engine v3.1.0 #5807 as the live-discovered defect) — per this repo's issue-scope convention, that should be explicit and accepted rather than silently unchecked.
• mcp-release-please.yml: the new block duplicates the `git add`/`commit -m`/`push origin "HEAD:$branch"` sequence from the package-lock.json branch above it verbatim aside from the file/message; consider factoring both into a small shell function to avoid drift if the commit pattern ever changes.
• Consider extracting a `commit_if_changed <file> <message>` helper used by both the package-lock.json and expected-engine.version sync steps in mcp-release-please.yml to keep the two nearly-identical blocks in sync going forward.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 45 registered-repo PR(s), 37 merged, 260 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 45 PR(s), 260 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: clean · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed). LLM value judgment: moderate — The change closes a concrete, live-observed CI failure (test:engine-parity failing on every engine release branch per #5807) with a minimal, well-scoped addition that mirrors an existing proven pattern in the same job.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 45 PR(s), 260 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review