fix: cap helm provider to < 3.0.0 for legacy set block compatibility

[KOCEAN33]

What

Pin the hashicorp/helm provider upper bound to < 3.0.0 in versions.tf.

Why

The helm provider 3.0 migrated to the Terraform Plugin Framework and replaced the nested set, set_sensitive, and postrender blocks with list/object attributes (set = [{ ... }]). This module (main.tf) still uses the legacy dynamic "set" block form, so it is incompatible with helm >= 3.0.

The constraint was previously open-ended (>= 2.10.1), meaning only a committed .terraform.lock.hcl stopped 3.x from being resolved. Any of these breaks apply with unsupported-block errors:

• terraform init in a fresh checkout without the lockfile
• terraform init -upgrade
• deleting/regenerating the lockfile

This is a minimal holding fix that keeps the current 0.1.x line working on the compatible 2.x provider. It does not add helm 3.x support: that requires migrating the block form to the attribute form and bumping the lower bound to >= 3.0, which is a separate change.

Refs #7

Verification

$ terraform init -backend=false
$ terraform validate
Success! The configuration is valid.
# helm resolves to 2.17.0

Signed-off-by via git commit -s (DCO).

[KOCEAN33]

@csantanapr would you be open to reviewing this one? Thanks for gitops-bridge, by the way; it's been solid for us. This is small but time-sensitive.

hashicorp/helm 3.2.0 is now published, and this module's constraint had an open upper bound (>= 2.10.1). Because main.tf still uses the legacy dynamic "set" block form (incompatible with the provider 3.x attribute API), any fresh terraform init or init -upgrade that resolves helm 3.x breaks apply; only a committed lockfile was holding it back. This PR just caps the 0.1.x line to < 3.0.0 so existing consumers stay on the compatible 2.x provider. Refs #7.

As a follow-up I opened #12, which does the full migration to the helm 3.x attribute API and bumps the floor to >= 3.0.0 (suggested as a 0.2.0 release). It builds on the direction in #8 and also updates versions.tf and the tests/complete provider config. The idea is to keep the two lines separate so 2.x users aren't forced to upgrade.

Does that split sound right to you, and would you be able to review/release when you have a moment? Happy to adjust either PR.