Pin the RTK version via `.config.rde.qovery.yml` instead of tracking `master`

Start with the template Dockerfile and .config.rde.qovery.yml, then inspect the RDE install flow and RTK's available tagged releases and checksums. Confirm how the pinned value is consumed and whether a stable, checksummable artifact exists. Done means the image builds with the configured version, verifies it before execution, and preserves the existing rtk init -g hooks.

Problem

In the template Dockerfile, RTK is installed by piping an install script fetched from the master branch straight into sh:

# RTK — reduces LLM token consumption by 60-90% on shell commands
RUN curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh \
  && ln -sf /root/.local/bin/rtk /usr/local/bin/rtk

This has two weaknesses:

1. Unpinned version. refs/heads/master is a mutable branch HEAD that changes on every upstream commit, so two builds of the same image can install different RTK versions with no record of which one shipped. Builds aren't reproducible.
2. No integrity check. The install script is fetched and executed with no checksum, so a changed or compromised upstream artifact runs undetected.

Proposed change

1. Pin the version through .config.rde.qovery.yml, the documented source of truth for component versions in the RDE install flow (see Qovery/documentation#143). The rtk component key accepts a version string and currently defaults to latest; set it to an explicit released version so the build installs exactly that, instead of tracking master:

# .config.rde.qovery.yml
rtk: "<pinned-version>"   # was: latest (tracks master)

2. Verify integrity of the RTK artifact before executing it. Once a version is pinned, the downloaded RTK install script (or release artifact) should be checksum-verified with sha256sum -c against a known-good SHA256 before it runs, so a tampered or unexpectedly-changed download is rejected rather than executed.

The template should consume the pinned, verified value when installing RTK rather than hardcoding the unverified master fetch in the Dockerfile.

Acceptance criteria

• The RTK version is declared as an explicit, pinned version in .config.rde.qovery.yml (not latest, not true)
• RTK is installed at the version declared in .config.rde.qovery.yml, not from the master branch
• The downloaded RTK artifact (install script or release binary) is checksum-verified (sha256sum -c) against a pinned SHA256 before execution
• Bumping RTK requires only a change to .config.rde.qovery.yml (and its associated checksum)
• Image builds successfully and rtk runs in the container (existing rtk init -g hooks still work)

Note

rtk's documented default is latest, so this is about choosing a pinned version for the template's own config rather than adding a new mechanism. If rtk-ai/rtk does not currently publish versioned release tags (and a stable, checksummable artifact per release), that's a prerequisite worth raising upstream — both pinning and checksum verification are only meaningful against a stable, tagged version.