Fixes missing permissions in staging workflow

[lucas-koontz]

Description

Adds necessary permissions for GitHub Actions in the staging workflow to ensure seamless integration.

Type of change

• 🐛 Bug fix (non-breaking change which fixes an issue)

Verification Process

To ensure the changes are working as expected:

• Test Location: Verify the workflow on the staging environment
• Verification Steps: Trigger a workflow through a pull request and ensure all steps execute without permission errors.

Additional Media:

• I have attached a brief loom video or screenshots showcasing the new functionality or change.

Checklist:

• My code follows the style guidelines(PEP 8) of MindsDB.
• I have appropriately commented on my code, especially in complex areas.
• Necessary documentation updates are either made or tracked in issues.
• Relevant unit and integration tests are updated or added.

[entelligence-ai-pr-reviews]

EntelligenceAI PR Summary

This PR expands permissions in the staging build/deploy GitHub Actions workflow to enable additional CI/CD capabilities.

• Added pull-requests: write permission to allow the workflow to comment on pull requests
• Added pages: write permission to enable GitHub Pages deployment from the workflow
• Added id-token: write permission to support OIDC token-based authentication

---

Confidence Score: 3/5 - Review Recommended

Likely safe but review recommended — this PR adds pull-requests: write, pages: write, and id-token: write permissions to the staging workflow, which are meaningful privilege expansions that warrant human review even in the absence of automated findings. The changes appear intentional and the described use cases (PR commenting, Pages deployment, OIDC authentication) are legitimate CI/CD patterns, but permission escalations in workflow files carry inherent security surface implications that should be verified against the principle of least privilege. A reviewer should confirm that all three permissions are actually exercised by steps in this workflow and that no overly broad scope is being granted unnecessarily.

Key Findings:

• Adding id-token: write enables OIDC token generation for the entire workflow, which could allow any step in the job to request cloud credentials — this should be scoped as narrowly as possible and verified that only the intended deployment step uses it.
• The pull-requests: write permission grants the ability to modify PR content, labels, and comments; this is appropriate if the workflow posts deployment previews or status comments, but the PR summary does not confirm a specific step in the workflow exercises this capability.
• Adding pages: write to a staging workflow is reasonable for preview deployments, but the reviewer should confirm this is not inadvertently deploying to production GitHub Pages, and that environment protection rules are in place.
• No automated issues were flagged and the file coverage is limited to the workflow YAML itself, which is consistent with a targeted permissions-only change — the intent is clear and the diff is narrow in scope.

Files requiring special attention

• .github/workflows/staging.yml