live-plan -json: the first plan after an apply reports marker binds with no identity

[lex00]

Measured while re-recording INTENTIUS/chant's live-root fixture against the v0.15.0 release binary (chant #2241, which is the chant-side half of #962 / PR 963). Not a regression: v0.14.0 does the same.

What happens

On the first live-plan -json after a choudoufu apply, every row in bound[] whose source is "marker" comes back with no identity field at all. Re-running the same command in the same directory a minute later fills it in. The derived row is unaffected in both runs, because its identity comes out of the configuration rather than off the live object.

First run after the apply:

{ "addr": "aws_cloudwatch_log_group.app", "type": "aws_cloudwatch_log_group",
  "identity": "/stateless-e2e-block/app",
  "identity_values": { "name": "/stateless-e2e-block/app" }, "source": "derived" },
{ "addr": "aws_eip.pool[0]",       "type": "aws_eip",            "source": "marker" },
{ "addr": "aws_security_group.main","type": "aws_security_group","source": "marker" },
{ "addr": "aws_vpc.main",          "type": "aws_vpc",            "source": "marker" }

A later run, same working directory, same estate, same emulator:

{ "addr": "aws_cloudwatch_log_group.app", "type": "aws_cloudwatch_log_group",
  "identity": "/stateless-e2e-block/app",
  "identity_values": { "name": "/stateless-e2e-block/app" }, "source": "derived" },
{ "addr": "aws_eip.pool[0]",        "type": "aws_eip",            "identity": "eipalloc-97cdd2ced8825b5da", "source": "marker" },
{ "addr": "aws_security_group.main","type": "aws_security_group", "identity": "sg-9038a29ced36e1bb7",       "source": "marker" },
{ "addr": "aws_vpc.main",           "type": "aws_vpc",            "identity": "vpc-dc8685c5",               "source": "marker" }

Why it reads as a defect rather than as a timing fact

The row still says source: "marker", so a consumer is told the instance was admitted by reading an ownership marker, and then given nothing to say which live object that marker was on. A tag-index lag would explain not finding the object; it does not explain reporting a marker bind for an object whose identity the document then omits. Whatever the bind rested on in the first run (the record store looks like the candidate, .tofu-records/ was present), the source value and the missing identity disagree.

Downstream it costs a real answer: chant's describeResources() publishes bound[].identity as the resource's physicalId and has to fall back to the configuration address when it is absent, so the first observation after an apply reports every marker-owned resource by address rather than by id.

Reproduce

• binary: published release choudoufu v0.15.0 darwin_arm64, SHA256SUMS-verified (db29573cb7d8dfa7205eeaecc0e4bcf154e941b8bb8179fb93ad53ac5c959409). Same behaviour on v0.14.0 (41c705d9b5fec47100c4f2fb9ab0694f0160b31a4e0661e877b4d9821bc464e3).
• emulator: this repository's pinned floci, ghcr.io/lex00/floci@sha256:a39185cc3971d0188663d61043cb038dff1260d8a975b1aa72c4e2bb1feac3cb, from live/smoke/docker-compose.yml.
• root: chant's lexicons/terraform/src/__fixtures__/live-estate/, which is derived from this repository's own live/e2e/estate-block/ plus an estate.chdf.hcl sidecar naming stateless-e2e-block.

choudoufu init
choudoufu apply -auto-approve
choudoufu live-plan -detailed-exitcode -json     # marker rows carry no identity
choudoufu live-plan -detailed-exitcode -json     # they do

Neither -estate nor TOFU_LIVE_COLLECT_UNCLAIMED changes it: all four combinations of the estate form and the sweep setting show the identity once the first run has happened, and none of them shows it on the first.

Recorded on chant's side in lexicons/terraform/src/__fixtures__/live-estate/README.md, which is why that fixture's plan document is deliberately not the first plan after its apply.