fix(ci): restrict Frontstage publication to upstream

[Sande33p]

Summary

• Keep Frontstage pull-request validation enabled in all repositories.
• Restrict non-PR build/publication and deployment to the upstream repository, matching existing release-workflow guards.
• Extend the existing workflow safety smoke and run it in Frontstage CI, including its path in both PR and push filters.

Behavior

Repository/event	Validation build	Publication
Any repository, pull request	Runs	Never
Fork, push/schedule/manual	Skipped	Never
Upstream, push/schedule/manual	Unchanged	Unchanged

Fork publication no longer requires a stargazer credential. Scheduled workflow records may still appear, but their jobs skip. No secrets or repository settings are changed, and an existing published website is not removed.

Validation and review

• Existing workflow smoke passed at baseline; the extended test failed before the fix and passed afterward.
• Workflow, stargazer-fetch, README star-history, and Developer Book publication smokes passed.
• Parsed YAML: all 12 repository/event combinations passed; 10 unsafe mutations were rejected. Baseline comparison confirmed all other triggers, steps, token permissions, and concurrency settings are unchanged.
• Focused Ruff and diff hygiene checks passed.
• loopx canary premerge --from-git-diff passed: direct diff/compile checks, all three selected catalog canaries, and the public/private boundary scan. No failed/skipped selected checks or canary manual holds. The standalone boundary check had only expected missing-registry warnings in the clean worktree.
• Independent local review found no blockers. Hosted PR checks remain the full Node/browser/docs validation; no live publication was requested.

Changed surfaces: GitHub Actions publication admission and its existing source-contract smoke. This risk-based coverage exercises PR preservation, upstream parity, fork credential isolation, and negative gate regressions. Merge remains subject to PR review and hosted checks.

Placement/future-facing pass: the existing Frontstage workflow and smoke own this behavior; no product capability, provider, or new abstraction is needed. Job-scoped assertions replace reliance on unscoped guard-string presence for the changed boundary.

[loopx-agent]

This fork-publication isolation looks useful beyond the HPC package. The current LoopX upstream workflow still admits non-PR builds/deployments without a repository-level guard, so the small policy boundary is worth proposing upstream.

Would you be interested in opening a focused PR at https://github.com/loopx-project/loopx for the workflow and its existing smoke? Please rebase the guard onto today's organization identity, loopx-project/loopx: the older huangruiteng/loopx literal in this head would block publication in the current upstream. Keep PR validation enabled for forks and add counterfactuals for fork push/schedule/manual events and upstream PR/non-PR events.

We read the patch and compared the current workflow source; the validation results in this PR remain author-reported here. This is a contribution invitation, not a compatibility or merge promise. Please retain attribution/license notices and DCO sign-off. The scientific campaign package and scheduler diagnostics can be assessed separately under their existing optional-provider boundary.