A floating provider constraint resolves differently on terraform and opentofu, and the Exoscale safety floor has no margin left

[stephrobert]

The three stacks that use a floating provider constraint do not resolve to
the same thing on the two engines this repository drives, because
registry.terraform.io and registry.opentofu.org do not index in step.

Measured 2026-09-14, reading both registries and applying each stack's own
constraint:

provider	constraint here	terraform init -upgrade takes	tofu init -upgrade takes
exoscale/exoscale	>= 0.71.0	0.72.0 (85 stable versions listed)	0.71.0 (84 listed)
outscale/outscale	~> 1.7	1.8.0	1.8.0
scaleway/scaleway	2.82.0, exact	2.82.0	2.82.0

The Exoscale row is two different pieces of software driving the same pack,
and nothing says so. The terraform leg and the opentofu leg both report
"the Exoscale provider passes" while running v0.72.0 and v0.71.0 respectively.
docs/clients.md already says a constraint's resolved version "is not knowable
here"; this is a step further — it is not the same on both legs.

The Outscale row agrees today by luck, not by construction. The same divergence
window applies to it whenever outscale/outscale publishes.

Why this is more than untidiness, for Exoscale specifically

terraformProviderFloor is v0.71.0 (internal/providers/exoscale/pack.go),
and the reason is recorded: below it, the provider honours
EXOSCALE_API_ENDPOINT for only half of its calls and the rest reach a paying
account — 57 requests, measured in #525.

So the opentofu leg currently resolves to exactly the floor, with no margin
at all. It is not below it, and guardSplitClients would refuse a client that
were. But the distance between "safe" and "the case the floor exists for" is
currently zero, and it is held there by a registry's indexing schedule rather
than by anything in this repository.

What is not being claimed

• Nothing is broken right now. Both legs are green, and the guard holds.
• This is not an argument that every constraint must become an exact pin. The
  Scaleway fixture is exact for a stated reason (The Scaleway Terraform provider moved half a product to instance/v2alpha1, four hours before it broke every apply #257) and the others are
  floating for a stated one.

What would settle it

Some way for a run to state which version answered, rather than leaving it
to be reconstructed from a registry days later. The conformance score already
records which client drove each operation; the provider version is the piece it
does not carry. At minimum, the Exoscale stack could pin at or above the floor
rather than floating from it, so the safety margin stops depending on indexing
latency.

Measurement scripts used are throwaway; the numbers above are reproducible by
reading /v1/providers/<ns>/<name>/versions on both registries and applying the
constraint written in each stack.

[stephrobert]

The Exoscale divergence has closed, about forty minutes after it was
measured. Re-measured the same way, 2026-09-14 at 18:1x:

	terraform	opentofu
stable versions listed	85	85 (was 84)
>= 0.71.0 resolves to	0.72.0	0.72.0 (was 0.71.0)

So anybody reading this issue tomorrow will measure 0.72.0 on both engines and
conclude the report was wrong. It was not: the window was real, and it is
recorded here rather than left to be rediscovered.

What closing changes, and what it does not.

It removes today's instance. It removes nothing about the mechanism: the two
registries still index independently, so the window reopens at every
publication. It reopened for Scaleway in the same hour — v2.83.0 was tagged on
GitHub at 15:06, absent from both registries at 17:2x, served by
registry.terraform.io alone at 17:35, and served by both at 18:1x. Three
distinct states in three hours, on one release.

That timeline is the argument, better than the snapshot was. A constraint does
not resolve to a version; it resolves to whatever a registry happens to be
serving at the minute the runner asks, and the two runners this repository uses
ask different registries.

The safety point stands unchanged. While the window was open, the
opentofu leg resolved to exactly terraformProviderFloor — the version below
which the provider sends 57 requests to a paying account (#525). The margin was
zero for about forty minutes, held there by an indexing schedule. Next time the
lower of the two could be below the floor, and then it is guardSplitClients
alone that stands between a green-looking run and a billable one. That guard is
the right last line; it should not be the first.