#22578: CI: enforce explicit workflow token permissions

## Summary - add explicit top-level `permissions` declarations to workflows that previously inherited repository defaults (`ci.yml`, `install-smoke.yml`, `workflow-sanity.yml`, `sandbox-common-smoke.yml`, `docker-release.yml`) - keep release workflows least-privileged by default with `permissions: {}` and preserve existing job-scoped write grants - add `scripts/check-workflow-permissions.py` and wire it into `workflow-sanity.yml` to enforce explicit top-level workflow permissions going forward ## Why This addresses the least-privilege gap tracked in #11763 by removing implicit token scope inheritance in CI workflows. ## Validation - `python3 scripts/check-workflow-permissions.py` - `python3 scripts/check-composite-action-input-interpolation.py` <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR enforces explicit workflow token permissions as a security hardening measure. All workflows now declare top-level `permissions` blocks (either `contents: read` for read-only workflows or `permissions: {}` for release workflows with job-scoped grants). A new enforcement script prevents future workflows from inheriting implicit repository-default permissions. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The changes are purely additive security hardening with no behavioral changes to existing workflows. The permission declarations match the actual requirements of each workflow, and the enforcement script correctly validates top-level permissions declarations without false positives. - No files require special attention _{Last reviewed commit: 73efd1d} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->