feat(parser): parse terraform show -json state files

[asakaxgit]

First of three small PRs for ROADMAP K.1 (c3x usage sync, #97, design in #99). Split so each can be reviewed alone: this one, then the synced-usage-file loading, then usage sync itself with S3 storage.

What

terraform show -json on a state has a top-level values where a plan has planned_values. Passing a state to the plan parser today returns zero resources and no error.

• plan.ParseStateFile / ParseStateBytes read values with the existing collectPlanned module walker (same shape as planned_values).
• parser.ParseState wraps it with the usual applyInheritance / applyResourceRegions, like PlanBaseline and ParsePostApply.
• A plan passed by mistake is rejected with an explicit error instead of silently yielding nothing; an empty state is not an error.

Why

Design §4 makes state the source of truth for mapping aws_s3_bucket.data to the real bucket name, and values.region gives the region the provider reported. Ref.Label() of a state resource equals the state address, which is also the resource_usage key.

Nothing calls ParseState yet, so there is no behaviour change.

Tests

go test -race ./internal/parser/...: module and indexed addresses, data sources skipped, region from values.region, empty state, plan rejected, invalid JSON, missing file.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[andreacappelletti97]

Thanks for this, and for splitting the work into three reviewable pieces. The approach is right: reusing collectPlanned for values, the same enrichment as Parse, and rejecting a plan instead of returning nothing. I ran the full suite on your branch and it passes.

Two things I'd like fixed here, since usage sync will sit on top of this:

1. A raw terraform.tfstate returns zero resources and no error. Passing the state file itself rather than terraform show -json output is an easy mistake, and it hits the same silent failure this PR removes for plans. A raw state has a top-level version and resources and no values; could ParseStateBytes reject it with an error that says to run terraform show -json?

2. Deposed objects are returned alongside the current one. While a create_before_destroy replacement is in progress, state lists the old object with a deposed_key under the same address as the new one. Both come back today, so one address would map to two cloud resources. Skipping entries with a deposed_key in the state path (a field on plannedResource would do it) keeps one resource per address.

A test for each would be great. Everything else looks good to me.