(temp): Add devkit power on workflow

[JoshuaMoelans]

No description provided.

[sentry]

Bug: The workflow is configured to trigger only on changes to its own file, making it impossible to run after the initial pull request is merged.
_{Severity: HIGH}

Suggested Fix

Replace the pull_request trigger with workflow_dispatch. This will allow users to manually run the workflow from the GitHub Actions UI whenever the devkit needs to be powered on, aligning the trigger mechanism with its operational purpose.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: .github/workflows/devkit-power-on.yml#L3-L8

Potential issue: The `devkit-power-on.yml` workflow is configured to trigger on
`pull_request` events with a `paths` filter that only includes its own file. This means
the workflow will run once when this pull request is merged, but it will become
impossible to trigger again in the future. Since the workflow's purpose is to power on a
devkit—an operational task that needs to be performed on-demand—this trigger
configuration renders it non-functional for its intended use after the initial merge.
The commit message suggests the `workflow_dispatch` trigger was intended but was
replaced for testing.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

To fix the problem, explicitly set permissions so the GITHUB_TOKEN has only the minimal required access. Since this job only runs prospero-ctrl power on and does not touch repo contents, we can safely set contents: read at the job (or workflow) level. This documents the intended permission level and prevents unintentional escalation if repository defaults change.

The best fix with no behavior change is to add a permissions block under the power-on job definition in .github/workflows/devkit-power-on.yml. Insert it alongside runs-on and timeout-minutes. For example, between runs-on (line 12) and timeout-minutes (line 13), add:

    permissions:
      contents: read

No additional imports, methods, or definitions are needed because this is a YAML configuration change only.

[JoshuaMoelans]

closing in favor of doing this in repo with selfhosted access instead

[sentry]

Bug: The pull_request trigger on a self-hosted runner allows forks to execute arbitrary code on the physical devkit by modifying the workflow file in their pull request.
_{Severity: CRITICAL}

Suggested Fix

Avoid running workflows from forks on self-hosted runners. Change the trigger to pull_request_target and ensure you explicitly check out code from a trusted source, not the PR head. Alternatively, restrict this workflow to run only on internal branches and not from public forks, or use ephemeral Just-In-Time (JIT) runners that are destroyed after each job.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: .github/workflows/devkit-power-on.yml#L3-L16

Potential issue: The new workflow `devkit-power-on.yml` is configured to run on a
`self-hosted` runner (`playstation` devkit) when a pull request is opened. Since the
repository is public, an attacker can fork it, add malicious commands to their version
of `devkit-power-on.yml`, and open a pull request. GitHub will execute the attacker's
modified workflow, granting them arbitrary code execution on the physical devkit. This
could be used to disrupt development, damage the hardware, or exfiltrate credentials.
The `paths` filter on the workflow file itself facilitates this attack vector.