fix(ci): don't skip fork-PR label reconciliation on schedule/workflow_dispatch runs

[roomote]

What problem this solves

label-pr-review-state.yml's reconcileLabels() skipped label mutations for any fork PR, regardless of what triggered the workflow run. That was overly broad: only pull_request/pull_request_review runs triggered from a fork actually get a read-only GITHUB_TOKEN (which 403s on label writes). The hourly schedule cron and manual workflow_dispatch runs always execute in the base repo's context with a full read/write token, even when the PR they're reconciling happens to come from a fork.

As written, this meant stale awaiting-author / awaiting-review / stale-awaiting-author labels on fork PRs would never get cleaned up by the scheduled reconciliation pass — only PR-triggered events could skip them, and those were exactly the runs that couldn't write labels anyway.

Why this change was made

Added isReadOnlyRun, which checks whether this run's own trigger (context.payload.pull_request) is itself a fork PR — true only for pull_request/pull_request_review events fired from a fork. reconcileLabels now skips a PR's label mutation only when both isReadOnlyRun && isForkPR(pr) are true, so schedule/workflow_dispatch runs reconcile fork PRs normally, while PR-triggered runs on a fork's own PR still avoid the guaranteed 403.

Verified against GitHub's documented GITHUB_TOKEN permission model (read/write for schedule/workflow_dispatch, read-only only for fork-triggered pull_request), and validated the updated skip logic against all six realistic trigger/PR-origin combinations.

User impact

Fork PRs now get their review-state labels correctly reconciled by the hourly schedule and manual dispatch runs, instead of silently never receiving label cleanup.

[roomote]

No code issues outstanding; 1 check still pending. See task

• Fallback truncation still walks the raw stored history, so earlier-condense conversations can report a truncation without actually shrinking the effective API history.
• getEffectiveVisibleIndices() still counts messages that getEffectiveApiHistory() drops when they only contain orphan tool_result blocks after a fresh-start condense, so fallback truncation can still spend its slice on non-effective history.
• CI is still pending for platform-unit-test (windows-latest).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[edelauna]

@roomote can you review

[roomote]

I started a PR review task for this request. See task

[roomote]

Addressed the latest follow-up review comment in 0755fa5.

Fallback truncation now derives its candidate indices from the same effective-history filtering used for provider requests, including fresh-start cleanup of orphan tool_result-only messages after condense. I also added a focused regression for that path.

Validation:

• pnpm --dir src exec vitest run core/context-management/__tests__/truncation.spec.ts core/context-management/__tests__/context-management.spec.ts core/condense/__tests__/index.spec.ts
• pnpm --dir apps/web-roo-code test

The code review item is fixed; GitHub checks are still running.