feat: add Valkey 9.1 and move 9.0 to 9.0.6

[spron-in]

What

• New 9.1 version bundle running Valkey 9.1.2 (latest valkey/valkey 9.1 release).
• The 9.0 bundle moves from 9.0.0 to the 9.0.6 patch release. Instances on the 9.0 bundle pick up 9.0.6 after the provider upgrade.
• 9.0.0 stays in the catalog marked deprecated, so Instances that pin it keep working and get the ComponentVersionDeprecated condition.
• The default bundle for new Instances stays 9.0.
• Examples used version: "9.0.0", which is not a bundle name; they now use "9.0".

valkey-operator v0.7.1 supports 9.1: it version-gates 9.1-only features (tls-auto-reload-interval, certificateUser: URI) and runs its TLS e2e against valkey/valkey:9.1.0.

Tests

• New chainsaw suite versions: an Instance on 9.0 renders valkey/valkey:9.0.6; switching it to 9.1 renders valkey/valkey:9.1.2.
• The cluster and replication suites and test/vars.sh now expect 9.0.6.
• Unit tests, lint, and all chainsaw suites pass locally.

Also checked on k3d with the real operator (v0.7.1):

Check	Result
New 9.0 replication Instance	runs 9.0.6
New 9.1 cluster, 3 shards	runs 9.1.2, cluster_state:ok
9.0 Instance switched to 9.1	both pods rolled to 9.1.2, Instance back to Ready, data kept
Instance pinned to 9.0.0	runs 9.0.0 with ComponentVersionDeprecated

Not in this PR

• The 8.1 bundle is unchanged. It does not start with operator 0.7.x, which always renders shutdown-on-sigterm failover (Valkey 9.0+). It should be removed or deprecated separately.
• With 9.1 available, tls.certificateUser: uri (Support mTLS client certificate authentication (valkey-operator v0.7 clientAuth) #15 follow-up) becomes possible.