[ilhan007]

Two updates to the dev-close notice workflow.

1. Read the release schedule from the tracking issue

Instead of hardcoding DEV_CLOSE_PERIODS in the workflow, the mode-decision step now fetches issue #10568 and parses the release-schedule Markdown table on it. When the schedule slips a day or two — which happens — the issue is edited in place and the workflow follows on the next run, no PR needed.

• Parser is column-scoped (Dev Close + Release only), so a typo in the Dev Start column doesn't poison the row.
• Rows with unparseable dates are skipped with a warning rather than failing the whole run.
• Multiple yearly tables in the same issue (## 2026, ## 2027, …) merge into one list — appending next year's schedule is a pure issue edit.
• permissions.issues: read added so the workflow can GET /issues/:n.

2. Add a follow-up 'clear-to-merge' comment

When the workflow runs on a schedule / workflow_dispatch outside a dev-close window, it now sweeps every open PR that already carries the dev-close-notice marker and posts a one-shot follow-up telling the author the release has shipped and the PR can now be merged.

• New idempotency marker: <!-- dev-close-cleared -->.
• pull_request events outside a window remain no-ops so we don't churn comments on every PR event.
• Clear-mode path does no builds / no CEM work — pure comment plumbing.
• RELEASE / RELEASE_DATE are no longer required in clear mode.

Test evidence

Parser was run against the current issue #10568 body — all six 2026 rows extracted cleanly. A mocked multi-year body (## 2026 + ## 2027) confirms next year's table will be picked up when it's added.

Follow-up to #13633.