fix: pin srtool docker image version to 1.81.0

[1xGiraffe]

Description

Fixes the srtool build workflow by using Docker directly instead of srtool-cli, with a pinned image version matching rust-toolchain (1.81.0).

srtool-cli ignores rust-toolchain and always uses the latest container image (1.88.0), causing build failures:

error: `#[no_mangle]` cannot be used on internal language items

Changes

• Use docker run directly with pinned paritytech/srtool:1.81.0 image
• Add SRTOOL_VERSION env variable for easy version management
• Update Makefile srbuild target to use Docker directly
• Remove srtool_image workflow input (see note below)

Note on Removed Input

The srtool_image workflow input has been removed. It never worked as intended - it controlled the srtool-cli git tag (cargo install --tag), not the Docker image version.

This is not classified as a breaking change because:

1. This PR actually fixes the broken action
2. If srtool_image is specified via workflow_dispatch, it will simply be silently ignored by GitHub Actions

Related Issue

Workaround for chevdor/srtool-cli#40:

Currently the CLI always uses the latest available srtool container image. It ignores rust-toolchain.toml and there is no ability to specify what srtool container image using --image parameter.

Motivation and Context

Deterministic builds are critical for blockchain runtimes. The authorize_upgrade hash must be reproducible so validators and the community can verify the runtime WASM matches the source code.

By pinning the Docker image version to match rust-toolchain, we ensure consistent, reproducible builds.

How Has This Been Tested?

• Tested GitHub Actions workflow in a fork
• Local Docker build completes successfully with correct JSON output

Checklist:

• I have updated the documentation if necessary.
• I have added tests to cover my changes, regression test if fixing an issue.
• This is a breaking change.