fix(ci): require main ancestry for engine publish

[JSONbored]

Motivation

• Prevent the publish workflow from creating official @jsonbored/gittensory-engine releases from an unchecked, unmerged ref by enforcing that the dispatched commit is reachable from origin/main.

Description

• Add a git fetch --no-tags origin main + git merge-base --is-ancestor "$RELEASE_SHA" origin/main check to the validate job in .github/workflows/publish-engine.yml so the artifact is only built from a commit on the protected branch.
• Repeat the same merge-base ancestry check in the privileged publish job before creating the release tag and performing OIDC/npm publishing as defense in depth.

Testing

• git diff --check and npm run actionlint completed (actionlint used the WASM fallback after transient setup failures).
• npm run test:ci was executed but failed on a pre-existing drift (cf-typegen) unrelated to this change and reported worker-configuration.d.ts is stale; the new checks themselves do not introduce test failures.
• npm audit --audit-level=moderate could not complete due to the npm audit endpoint returning 403 Forbidden.

---

Codex Task

[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 93.74%. Comparing base (f46aa4a) to head (015bc20).
⚠️ Report is 52 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4362   +/-   ##
=======================================
  Coverage   93.74%   93.74%           
=======================================
  Files         387      387           
  Lines       36398    36398           
  Branches    13330    13330           
=======================================
  Hits        34120    34120           
  Misses       1621     1621           
  Partials      657      657           

🚀 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

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-09 04:45:33 UTC}

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

⏸️ Suggested Action - Manual Review

• 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.

Review summary
This PR adds a `git merge-base --is-ancestor "$RELEASE_SHA" origin/main` guard to both the unprivileged `validate` job and the privileged `publish` job in publish-engine.yml, blocking the workflow from tagging/publishing a commit that isn't reachable from `origin/main`. The check is placed immediately after each job's `fetch-depth: 0` checkout, uses `set -euo pipefail`, and fails the run with a clear `::error::` message — logically correct and consistent with the existing `npm-publish.yml` privilege-separation pattern referenced in the file's own comments. Duplicating the check in the privileged `publish` job is intentional defense-in-depth (a compromised/altered `validate` output shouldn't be trusted alone), which is the right call for a job holding `id-token: write` and `contents: write`.

Nits — 5 non-blocking

• publish-engine.yml:49-59 and :150-160 duplicate the identical 11-line ancestry-check block; consider factoring it into a small composite action or reusable script step to avoid drift between the two copies, though keeping it inline in both jobs is defensible as literal defense-in-depth.
• The new `git fetch --no-tags origin main` runs with `persist-credentials: false` from the checkout step; confirm anonymous/public read access is sufficient here (fine if the repo is public, but would fail with a permission error on a private repo before any auth step runs).
• The PR description doesn't reference an open issue per repo convention for closing/linking eligible issues — worth confirming this is either a maintainer-authored hardening fix or tied to a tracked issue before merging.
• Consider extracting the repeated ancestry-check into a composite action (e.g. `.github/actions/verify-main-ancestry`) shared by both jobs to keep the two checks from silently diverging over time.
• If this repo is private, add an explicit auth step (or confirm `GITHUB_TOKEN` grants read access) before the `git fetch` in both jobs so the new check doesn't itself become a source of workflow failures.

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.

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: 49 registered-repo PR(s), 41 merged, 504 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 49 PR(s), 504 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

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: 49 PR(s), 504 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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review