ci: Add top-level permissions block to workflows missing explicit permissions

[Gitanshi2211]

Part of Workstream 1 (CI architecture and workflow supply chain). Audited all 15 workflow files in .github/workflows and found 7 with no top-level permissions: block, meaning some jobs (e.g. run-lint, test, build-and-test) were inheriting default token permissions rather than an explicit least-privilege scope. This PR adds permissions: contents: read at the top level of each affected workflow as a safe baseline; job-level permission overrides (e.g. security-events: write in analyze) are unaffected.

Before: 7 of 15 workflows had no explicit permissions block
After: 15 of 15 workflows now have an explicit top-level or job-level permissions block

Next: pinning third-party actions to commit SHAs (separate PR).

[github-actions]

Preview Environment

A preview environment can be spun up on demand for this PR.

Action	Label	Includes
Spin up preview	deploy-preview	Frontend, backend, database, Redis, OPA, worker
Spin up preview with M365	deploy-preview-m365	Everything above + PowerShell service for Exchange/Teams scan testing
Tear down preview	teardown-preview	Stops the environment early

The environment will also be torn down automatically when the PR is closed or merged.
Preview URLs will appear in a follow-up comment once the deploy completes (~5–8 min).
M365 scans require real tenant credentials added through the frontend UI.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 87723da4c1

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Grant status write to Super-Linter jobs

This top-level block applies to run-lint, which has no job-level permissions but still passes GITHUB_TOKEN to github/super-linter@v4 with its multi-status behavior enabled by default. Because declaring permissions sets unspecified scopes to none, the token no longer has statuses: write, so backend, engine, and security lint runs can no longer create the --> Linted: ... commit statuses that Super-Linter posts via the statuses API; any PR checks or branch protection relying on those statuses will stop updating. Add statuses: write on the affected run-lint jobs while keeping contents: read.

Useful? React with 👍 / 👎.

[akshitpatel1732]

Hi @Gitanshi2211! Thanks for tackling the security supply chain improvements with these explicit permissions blocks.
A quick heads-up: it looks like this PR skipped our PR template. Going forward, please make sure to use the template as it helps us track testing details (like manual workflow run verifications).
Additionally, ChatGPT Codex caught an important edge case with the run-lint jobs:

• The Issue: Adding a top-level permissions block implicitly sets all unspecified permissions to none for any jobs that don't override them. The run-lint job relies on github/super-linter, which needs statuses: write permissions to post individual linter status checks back to the PR. Without it, these checks will fail or stop updating.
• The Fix: Please update the affected run-lint jobs to include their own explicit permissions block (keeping contents: read and adding statuses: write).

Could you please apply these fixes, test the modified workflows to ensure the linters report properly, and update the PR? Thanks again for your work on this!