fix(generator): Filter third-party services by active products

[JamesDuncanNz]

Description

This PR fixes a bug in the Magic Modules generator where handwritten files for Beta-only (or version-restricted) services were being leaked into the GA provider, causing compilation failures - example.

The Problem

When introducing a new Beta-only service (such as the upcoming agentregistry) that includes handwritten files in third_party/terraform/services/<service_name>/ (e.g., agent_registry_operation.go), the GitHub Actions "Provider Build and Unit Test" job fails during the GA provider compilation with:
undefined: Product

The Cause

1. During GA provider generation, the Beta-only service is correctly not generated, meaning product.go (which defines the Product variable) is not created in the GA provider.
2. However, the generator's CopyCommonFiles and CompileCommonFiles methods were blindly copying/compiling the entire third_party/terraform/services/ directory to the downstream provider.
3. This resulted in the Beta-only service's handwritten files (like agent_registry_operation.go) being copied to the GA provider (google/services/agentregistry/).
4. Since these handwritten files commonly reference the Product variable (which doesn't exist in GA for this service), the GA provider failed to compile.

The Solution

This PR modifies the generator to only copy and compile third-party service files for products that are actually active in the target version being generated:

1. Updated Signatures: Updated CopyCommonFiles in the Provider interface and all its implementations to accept the list of active products []*api.Product.
2. Filtered Copying: Modified getCommonCopyFiles in terraform.go to remove the global third_party/terraform/services copy. Instead, it now iterates through the active products and only copies third_party/terraform/services/<product_name> if it exists.
3. Filtered Compilation: Modified getCommonCompileFiles in terraform.go similarly to only compile templates for active products.
4. Helper Added: Introduced a dirExists helper in terraform.go to safely check if a service directory exists in the template filesystem before attempting to copy/compile it (as some services do not have handwritten files).
   This ensures that the GA provider remains completely free of any Beta-only service code, preventing compilation leaks.

Test/Verification Results

Verified locally by running:

1. make provider VERSION=ga (GA Generation) -> Verified that the google/services/agentregistry directory is no longer created in the GA provider, resolving the compilation leak.
2. make provider VERSION=beta (Beta Generation) -> Verified that the google-beta/services/agentregistry directory is correctly created and contains all generated and handwritten files.

Release Note Template for Downstream PRs (will be copied)

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit ea638db:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	60 files changed, 1450 deletions(-)

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes for commit 2bc9266:

Diff report

Your PR generated the following diffs in downstream repositories:

Repository	Diff Link	Changes
google provider	View Diff	63 files changed, 1453 deletions(-)

[github-actions]

Googlers: For automatic test runs see go/terraform-auto-test-runs.

@melinath, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[melinath]

This isn't exactly a bug in the provider generator... but it does seem like a reasonable change that fixes a class of potentially-confusing compilation errors. The downstream diff looks good.

@roaks3 do you think this would cause any problems with nightly?

[roaks3]

I can't immediately tell, is this fixing an urgent issue? If not, I would honestly probably hold off. It seems like more of a nice-to-have (if I'm understanding) that is touching a lot of core files with an LLM, and could break private providers in ways that are not obvious.

[melinath]

I'm not aware of an urgent issue this is fixing. +1 that it seems like a nice to have. Holding off seems reasonable.