[SOC2] Add top-level permissions blocks to reusable workflow files

[anandray]

Stage 1 of a 3-stage cleanup of Scorecard TokenPermissionsID findings (15 open alerts total). This issue tracks the mechanical batch fix: add a least-privilege permissions: contents: read block to the top of five reusable workflow files that currently have no top-level permissions declaration.

Files affected

File	Alert #	Current state
.github/workflows/_build.yaml	#513	no top-level permissions
.github/workflows/_docker.yaml	#514	no top-level permissions
.github/workflows/_init.yaml	#515	no top-level permissions
.github/workflows/_release.yaml	#516	no top-level permissions
.github/workflows/sync-models.yml	#605	no top-level permissions

Proposed change (each file)

# Add immediately after `name:`:
permissions:
  contents: read

Why this is safe

• All five are reusable workflows (used via uses: ./.github/workflows/_*.yaml from caller workflows)
• Reusable workflows can have job-level permissions raised when needed; the top-level acts as a default ceiling
• Existing job-level permissions: blocks within these files are unaffected
• contents: read is the default-safe baseline matching secret-scan.yml and ci.yml

Out of scope

• Category B (top-level writes in nightly.yaml, storage-cleanup.yml) — separate refactor
• Category C (job-level writes for release publishing) — documented justification + selective dismissal

SOC2 link

CC7.1 vulnerability management — closes 5 of 15 critical/high TokenPermissionsID findings on rocketride-server. Mechanical batch resolution following SECURITY.md disposition framework (Fix).

[github-actions]