policy: validate policies against provider schemas before the walk

[DanielMSchmidt]

Validate policies against the run's provider schemas before the plan/apply walk, so a policy that references an attribute a provider does not have fails early rather than partway through evaluation.

This is the terraform (host) side of the policy-plugin schema-validation feature. It only affects experimental policy runs (it's a no-op unless a policy client is attached).

What it does

When opts.PolicyClient is set, after loadSchemas builds the run's schemas and before the graph walk, terraform enumerates schemarepo.Schemas, encodes each provider's config / resource / data-source configschema.Block.ImpliedType() as a cty JSON type, and calls the plugin's new ValidateProviderSchemas RPC. The returned diagnostics are appended to the run diagnostics; an error blocks the run before any policy is evaluated against a real resource.

Why before the walk (not at Setup): Setup runs at the command layer and also serves init — before any Context or schemas exist. Schemas only exist inside terraform.Context, so the schema push is a separate post-Setup call. Insertion points:

• context_plan.go planWalk — loads schemas via c.Schemas (a cache hit after graph build) then validates, before c.walk.
• context_apply.go ApplyAndEval — reuses the schemas already loaded before the walk.

Changes

• internal/policy/proto/policy.proto: new ValidateProviderSchemas RPC + ProviderSchema / request / response messages (mirrors the plugin's proto for wire compatibility). Regenerated with make protobuf.
• internal/policy: ValidateProviderSchemas added to the Client interface, with the client implementation (cty JSON type encoding), host-side request/response types, and the MockClient.
• internal/terraform: a validateProviderSchemas helper (enumerates schemarepo.Schemas → the request; local names via Module.LocalNameForProvider) wired into planWalk and ApplyAndEval; a plan test covering both the "schemas sent, clean run" and "validation error blocks the run early" paths.

Dependencies

• Requires the plugin RPC: hashicorp/terraform-policy-plugin#82 (which in turn depends on the shared engine, hashicorp/terraform-policy-core#95).

Target

• Experimental (AllowExperimentalFeatures); no behavior change for non-policy runs.

[jbardin]

What about ephemeral and list types?
With a lot of resources changing sensitive values to read_only inputs, checking against ephemeral resources might also be important (does not not exist in the policy language?)
Even if these are existing holes in the policy language, having support for them on the core side means it all works can work when the holes get filled.