- remove needless \") from duplicate slices message
- add stripBase to have only relative slice path in the message

Ensure that only valid types are allowed for the `essential` field: sequence in v1/v2 and map in v3.

Bump the minimal go version to 1.25.8, fixing the following vulnerabilities, affecting go 1.24.6:

CVE-2025-68121 (CRITICAL)
CVE-2025-58183 (HIGH)
CVE-2025-61726 (HIGH)
CVE-2025-61728 (HIGH)
CVE-2025-61729 (HIGH)

go 1.24.13 cannot be used as it is not available yet in the snapstore.
go 1.26 cannot be used either as there is no stable snap of it in the snapstore.

govulncheck does not identify any vulnerabilities after this fix.
trivy does not identify any stdlib-related vulnerabilities after this fix.

golangci-lint is also bumped to v2.x to be compatible with go 1.25. To do so, the configuration is migrated to the v2 format, with the minimum amount of changes. Some checks are excluded to avoid unrelated fixes in this PR. They should be re-enabled in a follow-up PR and the code corrected.

Pin all actions used in workflows with hashes.
This also bumps setup-go and checkout actions version as I expect no breaking
change given how they are used.

Remaining actions not pinned in this PR are pinned or reworked in other PRs (see
#275, #274, #272)

Trivy was previously executed on the main branch, so the report was not
reflecting the level of vulnerability in the binary actually distributed to
users. Moreover, fs type scan only uses the go version from go.mod as a
hint and so cannot conclude on the stdb lib actually used to build the binary.
As a consequence, the report produced was imprecise and incomplete.

This PR does two main changes:
Run the scan on the last release, on all architectures;
Run a rootfs type scan on the binary, ensuring the the std lib included
is analysed.
Actions are also pinned to protect against supply chain attacks on them.

Note: I manually tested both type of trivy scan on the binary and confirmed
only the rootfs one identifies the vulnerabilities in the std lib.

Do not expose the token used to write the comment to PRs from forks.
This also ensures that PRs open from external contributors will not trigger
the workflows.
In the workflow posting the comment, use a fine-grained token with the
minimum permissions (write PR and read Actions).