ci: skip scheduled workflows on forks and fix the Windows sandbox W0 lane

[Astro-Han]

Summary

Two CI problems that surfaced together.

Scheduled workflows on forks. Eight workflows with a schedule trigger have no repository guard, so every fork with Actions enabled runs them nightly against its own, usually stale, main. On forks they fail for reasons unrelated to any change: Dependency audit reports advisories already fixed upstream, and Release Windows check downloads its upgrade baseline (gh release download v0.2.0-dev.11.20260831 --repo <fork>) from releases that only exist on apache/maka. Each affected job now carries:

if: github.event_name != 'schedule' || github.repository == 'apache/maka'

Only cron runs outside apache/maka are skipped. Pull request, push and workflow_dispatch runs keep their current behavior, including on forks. Affected: dependency-audit, pr-effort-label, release-linux-check, release-windows-check, windows-acp, windows-baseline, windows-recovery, windows-sandbox-w0. issue-pr-lifecycle and model-metadata-upkeep already guard on the repository; npm-publication is gated by vars.NPM_NIGHTLY_ENABLED.

Windows sandbox W0. windows_sandbox_w0_protocol has failed on every main run since at least 2026-09-30. Two of the four tests in filesystem-worker-windows-smoke.test.js crash the worker at launch:

Error: Cannot read package config \\?\D:\a\maka\maka\package.json: operation not permitted.
code: 'ERR_INVALID_PACKAGE_CONFIG'  (node:internal/modules/run_main shouldUseESMLoader)

The worker bundle was emitted as dist/workers/filesystem-worker.js, so Node walks up to the nearest package.json to decide the module type, and the AppContainer sandbox denies that read. The bundle is now filesystem-worker.mjs, ESM by extension, with no lookup. FILESYSTEM_WORKER_BUNDLE_NAME stays the authority: the esbuild script and the desktop resource copy import it from the runtime build instead of repeating the literal. Packaging verifiers keep literal paths because they check the shipped layout on their own.

The pinned-version upgrade check verifies the previously released installer with the current resource list, and releases built before the rename ship filesystem-worker.js. The upgrade-baseline contract now relaxes that requirement, like the other resources newer builds added.

The same rename is part of #5969; this lands it without waiting for that feature.

Refs #5969

Verification

• actionlint on the eight workflows: clean.
• npm --workspace @maka/runtime run build emits dist/workers/filesystem-worker.mjs; node apps/desktop/scripts/copy-runtime-filesystem-worker.mjs copies it to resources/workers/filesystem-worker.mjs.
• packages/runtime: node --test over filesystem-worker*, linux-sandbox*, macos-seatbelt* tests: 126 pass, 8 skipped (platform-gated), 0 fail.
• Scripts that read the touched files (ci-test-plan, ci-workflow-policy, desktop-release-targets, desktop-nightly, product-release, source-legal-inventory, verify-windows-harness, verify-packaged-app*, windows-package-source-closure, release-cli-*): pass. verify-packaged-app.test.mjs now asserts the baseline contract does not demand the .mjs worker.
• npm run format, npm run lint: clean.
• On Windows: this PR's windows_sandbox_w0_protocol and package (pinned-version upgrade) runs.
• Not run: a scheduled run on apache/maka; the guard evaluates to true there, so the next nightly is the confirmation.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code diagnosed both failures, wrote the guards, the rename and the baseline relaxation, ran the checks above, and drafted this description.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[zhiiw]

Verified on a real Windows machine against 78c4a6f5c69af9a7ea353e96b0c3dd1bcefe9930 (head unmoved at posting; 19 check-runs all green, including windows_sandbox_w0_protocol):

• The schedule guards read correctly: if: github.event_name != 'schedule' || github.repository == 'apache/maka' on all eight jobs — non-schedule events on forks still run, scheduled lanes stay on the default repo.
• The bundle-rename follow-through is consistent: FILESYSTEM_WORKER_BUNDLE_NAME is the single source; the desktop copy script, electron-builder extra resources, the W0 verify scripts and the client tests all read .mjs. On this machine the runtime worker build produces dist/workers/filesystem-worker.mjs and the copy script consumes it.
• filesystem-worker-client.test.js: 25/29 with 4 failures, all attributed to this machine, not the PR — 3× symlink-fixture EPERM (no Developer Mode here) plus the fd-pin test (Linux-only directory-fd semantics). The identical failure set reproduces at a recent main commit (3ac02049) on this machine, so they are pre-existing environment noise.

No blocking issues.