feat: promote envprov to a loadable provisioner type

[Siddhartha-singh01]

Promotes the built-in envprov provisioner to a first-class, loadable provisioner type alongside templateprov and cmdprov.

Resolves #488

Description

The envprov.Provisioner was previously hardcoded in generate.go and always resolved environment variables via os.LookupEnv with no way for developers to override or configure it. As discussed with @chris-stephenson in #488, the cleanest path is to make envprov loadable through the existing provisioners YAML mechanism using a local-env:// URI scheme.

Changes:

• internal/provisioners/envprov/envprov.go: Added YAML struct fields and a Parse() function following the same pattern as cmdprov.Parse() and templateprov.Parse(). The provisioner works in two modes: legacy (created via new(Provisioner) with original behavior preserved) and YAML-loaded (created via Parse() with standard type/class matching).

• internal/provisioners/loader/load.go: Added local-env case to the URI scheme switch so the loader can parse and load environment provisioners from .provisioners.yaml files.

• internal/command/default.provisioners.yaml: Added a default local-env://default-provisioners/environment entry so new projects get the environment provisioner out of the box via score-compose init.

• internal/command/generate.go: Replaced the hardcoded new(envprov.Provisioner) with logic that searches loaded provisioners for an *envprov.Provisioner first, and falls back to creating one if not found (backward compatibility for existing projects).

What does this PR do?

Allows the environment provisioner to be loaded from .provisioners.yaml files like any other provisioner, instead of being hardcoded. Developers can now override or replace the default environment provisioner by defining their own local-env:// entry in a higher-priority provisioners file.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• New chore (expected functionality to be implemented)

Checklist:

• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• I've signed off with an email address that matches the commit author.

[chris-stephenson]

Not sure the fallback logic is correct.

[chris-stephenson]

I think this is the wrong check. You shoudl check for Type. The point here is that we want people to provide their own provisioners for environment - not force them to use the envprov implementation.

[Siddhartha-singh01]

Thanks for the catch @chris-stephenson, you're right.

I spent some time going back through the provisioner loading path again to make sure I understood how it all connects the loader, LoadProvisionersFromDirectory, and how ProvisionResources picks a provisioner by Match(). Once I looked at it properly, your point made sense: the old p.(*envprov.Provisioner) assertion was only checking "is this our built-in struct", which isn't the same question as "does this handle environment resources". So if someone supplied their own cmd:// or template:// provisioner with type: environment, it would get ignored and we'd force the built-in envprov on top anyway exactly what we don't want.

I've changed the check to match on p.Type() == "environment" instead. Now the built-in envprov fallback is only appended when no provisioner already claims the environment type, so a user-supplied one is used as-is.

One thing worth flagging: I kept the *envprov.Provisioner type assertion in one spot, but only as a non-fatal capture Accessed() (used to write the -env-file) is specific to the built-in implementation and isn't part of the Provisioner interface. When a custom provisioner handles environment, that reference is just nil, so I guarded the env-file write accordingly.

Build, go vet and the env/generate tests pass locally.

Could you take another look when you get a chance