[Fix] Sandbox yarn PATH and --no-verify git push delivery

[pridemusvaire]

What changed

Worker setup

• Worker setup enables Corepack yarn (corepack enable yarn + corepack prepare yarn@stable --activate + mise reshim) and verifies with yarn --version, so hooks that shell out to yarn no longer fail with yarn: not found.
• enable is scoped to yarn deliberately: the unscoped form also writes pnpm/pnpx shims next to the corepack binary, which the following reshim would publish ahead of the mise-managed pnpm.
• The Corepack download is bounded by a timeout, because it runs inside the serial setup block that gates task start. A throttled or unreachable registry degrades to a warning instead of hanging the boot.

Delivery skills

• The six delivery skills now always push with --no-verify. Local pre-push hooks re-run full lint/typecheck/test suites against host tooling the sandbox does not have, which produces false delivery failures that agents misreport as missing Git credentials.
• Skipping pre-push also skips whatever secret or policy scanner a repository hangs on that hook, and Roomote cannot verify that an equivalent server-side gate exists. So the skills say that plainly rather than claiming CI owns it, and every push is now preceded by a mandatory secret review of the outgoing patch.
• Agents are taught to classify a failed push by the source of the error. A rejection naming a secret, credential, or policy violation (including server-side push protection such as GH013) is a real finding to report and fix, never something to retry around with --no-verify.
• The pre-commit carve-out reaches all skills that commit into an existing repository, so --no-verify cannot generalise from pushes to commits.

Why this change was made

Sandbox pushes failed when a pre-push hook ran yarn that was not on PATH, and agents narrated that as a Git credentials problem. Local pre-push suites also differ from developer machines and false-block delivery.

Impact

New tasks get yarn on PATH during worker setup, and agents deliver without running sandbox-hostile pre-push hooks. In exchange the agent, not an assumed CI job, owns the secret check before every push.

Test plan

• apps/worker mise setup tests: 14 passing (was 7 before this branch)
• packages/cloud-agents workflow tests: 287 passing across 45 files, including a new prompt-invariant test that locks the push contract across all six delivery skills
• Mutation-checked both new suites: unscoped corepack enable, a removed timeout, ?? 1 → ?? 0, mise reshim <tool>, a swallowed warning, a secret review moved after the push, an opt-out clause, a reintroduced CI-owns-the-gates claim, a push demoted to a fenced block, and an inverted error classification all turn the suites red
• pnpm knip, oxlint, oxfmt --check, and tsc --noEmit clean in both packages
• CI green on this PR

[roomote-roomote]

No code issues found. See task

• packages/cloud-agents/src/server/workflows/skills/standard/create-draft-pr/SKILL.md:145: Always using git push --no-verify bypasses every repository's pre-push hook, including local secret and policy scanners. These skills run against arbitrary repositories, but no workflow verifies an equivalent CI/server gate before pushing, so repositories that rely on pre-push-only scanning can now publish secrets. Keep the normal push path, or narrowly retry without verification only for confirmed sandbox-tooling failures.

_{Reviewed 92c978c}