Bump Go version to 1.25 and fix broken GitHub CI

[plural-copilot]

This PR updates the Go version used in the project to 1.25 as requested.

• The go.mod file now specifies Go version 1.25
• All Dockerfiles referencing Golang base images have been updated to use Go 1.25
• The GitHub Actions CI workflow file (.github/workflows/ci.yaml) has been fixed:
  • Corrected the default checked out branch from 'master' to 'main'
  • Ensured Go version used in setup-go actions is fixed to 1.25
  • Cleaned up the CI YAML structure for clarity

These changes ensure compatibility with the latest Go version and restore a working CI pipeline.

To resolve the issue, explicitly set a permissions block at the workflow level or for each job, specifying the minimum required access, namely 'contents: read'. In this context, it's best to add a global workflow-level permissions block to .github/workflows/ci.yaml immediately after the name key and before on:. This applies to all jobs unless overridden and ensures that only the minimal repository content read access is provided to the GITHUB_TOKEN, mitigating risk in all contained jobs. No changes to steps or functionality are required, only the addition of the block.

---

To fix this issue, add an explicit permissions block at the top level of the workflow or at the relevant job level(s). The minimal and safest starting point is to give the workflow (or jobs) only contents: read access, which suffices for the actions shown (building, testing, linting code, and building Docker images), unless some jobs require additional permissions. This block should be placed after the workflow name: and before the other top-level keys like on:, env:, or jobs:.
The precise fix:

• Insert a permissions: key with contents: read at the root level (so it applies to all jobs).
  No new methods, imports, or definitions are needed; only the permissions block is required in .github/workflows/ci.yaml.

---

To fix this issue, you should add a permissions block at the top level of the workflow file .github/workflows/ci.yaml. This block should grant only the minimal privileges required for the workflow to run correctly, typically "contents: read" for workflows that only require read access for checking out code and building/testing it. You should place the permissions block immediately after the workflow name: field and before other top-level directives like on: or env:. If you have jobs in the workflow needing write permissions (not shown in the snippet), you would add a more permissive permissions block for only those jobs.

To address this issue, you should explicitly specify a permissions: block in your workflow YAML file to restrict GitHub Actions' GITHUB_TOKEN's access. If none of your jobs need to write to repository contents, or create issues, or PRs, the minimum safe value is contents: read, which is recommended by the CodeQL warning. This block should be added at the workflow root (top-level, so it applies to all jobs unless overridden) or within individual jobs. Since the workflow currently contains only build, test, lint, and image creation steps, none of which need write access to repo contents, placing permissions: contents: read at the top level is sufficient, and allows you to follow the least privilege principle without interfering with any job's functionality.

Make this change directly below the workflow's name: block, before the on: section begins, in .github/workflows/ci.yaml.

---

To fix the issue, you should explicitly set the permissions key in the workflow file to restrict the default permissions of the automatically generated GITHUB_TOKEN. Since the workflow only includes jobs for building, testing, linting, and building Docker images (with no indication that any steps require write access to the repository or related GitHub API objects), the minimal permission contents: read is likely sufficient for all jobs. The change should be placed at the root of the workflow file (directly under the name: and on: blocks) so that it applies to all jobs. This will ensure that if anyone adds permission-sensitive steps in the future, they'll have to explicitly escalate them. No extra imports, functions, or variables are required; this is a single YAML configuration addition.

---

To fix this issue, add a permissions block to the lint job that grants only the minimum required permissions for the job to work (which, for linting, is only contents: read). This block should be added inside the lint job definition, alongside name and runs-on, before steps. No additional imports or method changes are necessary, as this is a workflow configuration change.