test(flagd): run the provider conformance suite against both resolvers

[aepfli]

Stacked on #940. Base is feat/provider-tck, so this diff shows only the new work. Review #940
first — it describes the suite, the adoption API and the capability vocabulary, and none of that is
repeated here.

Part of #938 and open-feature/spec#417.

Adopts the conformance suite in the flagd provider, for both resolvers, in a new
providers/flagd/tck module.

They are two suites because they are separately conformant. flagd resolves flags two quite different
ways — RPC evaluates remotely over gRPC, in-process syncs the ruleset and evaluates locally — and any
difference between the two results is a difference an application would see when it switches
resolver, which is a configuration change rather than a code change. That is exactly the class of
thing this suite exists to surface, and it surfaced one.

flagd-testbed is not modified and the existing flagd e2e suites are untouched. They stay in
providers/flagd/e2e — a sibling module, not a parent. They test flagd against flagd's own
harness and are expected green; this suite tests the provider against the OpenFeature provider
contract and fails scenarios by design wherever a deviation is declared, so filing one under the
other would put two different meanings of red on one signal.

What it declares

	RPC	in-process
@events @lifecycle @configuration-change @object @variants @targeting @disabled-flags @standard-reasons @numeric-coercion @unavailable	declared	declared
@stale	withheld	declared
@reinitialization	withheld	withheld
@large-integers	withheld	withheld

Three of the four absences are decisions the specification permits, and the code says so at each one
rather than leaving a reader to guess:

• @stale on RPC. The RPC resolver emits PROVIDER_ERROR on connection loss and never
  PROVIDER_STALE; in-process emits STALE first and escalates to ERROR only when the retry grace
  period expires. So the two resolvers of one provider report an outage differently, and an
  application moving from in-process to RPC stops receiving stale events. Worth knowing — but
  requirement 5.1.1's supporting text offers both behaviours in the same breath ("can", twice), so it
  is a design choice and gets no known-deviation entry.
• @reinitialization. Requirement 2.5.2 is a SHOULD whose supporting text says "some providers
  MAY allow reinitialization from this state". Permitted, not required. This provider does not offer
  it. That scenario was mandatory until spec fc99d5ac and had been written down as a deviation
  against flagd before anyone read 2.5.2; gating it is the fix.
• @large-integers. flagd-testbed serves no flag for it, so no scenario gating it can be put to
  the provider at all. The withholding names
  flagd-testbed#392 so it is revisited when
  the backend gains the flag rather than outliving its reason.

The one known deviation

@numeric-coercion is declared, its scenario fails, and the failure is recorded beside it —
which is the shape Appendix F asks for. flagd narrows 0.5 to 0 through the integer accessor with
no error code, where the lossy half of its own accepted
coercion ADR
requires TYPE_MISMATCH. The lossless half works: 10 requested as a float widens cleanly. So the
provider coerces and gets one direction wrong, and withholding the tag could not have said that —
it would have asserted a defect at a question the suite never asked. Tracked against
flagd#1996.

The rule is flagd's own commitment rather than a specification requirement — the specification does
not define numeric coercion at all (spec#430) —
and the deviation's summary says so, so a consumer does not read it as a contract violation.

Running it, and the tally

make tck

Both suites run 65 scenarios: 61 pass, 4 fail. The four are the same set in both resolvers — the
coercion deviation above, plus three FLAG_NOT_FOUND failures where flagd-testbed v3.8.0 serves
neither integral-float-flag nor large-integer-flag. flagd-testbed#392 fixes all three at once.
None of the three gets a deviation entry, because an entry there would attribute a fixture gap to the
provider.

A red run with more than four failures is the testbed's readiness window, not this provider:
POST /start returns before flagd's file source has loaded the flags, so a stateless provider races
that load on every scenario. No sleep is being added to compensate — the control API's promise is
that a command has taken effect when it returns, and a suite that sleeps instead of holding it to
that promise stops being able to detect when it breaks.

Module wiring

providers/flagd/tck/go.mod is a module of its own, beside providers/flagd/e2e rather than inside
it, requiring tools/tck through a local replace. providers/flagd/e2e requires neither
tools/tck nor the spec assets any more — the spec pin moved with the files rather than multiplying.

Two targets, doing two different jobs:

• make tck runs this module. Nothing on a pull request does.
• make e2e builds it under -tags=tck with an empty -run, so a signature change in the harness
  cannot rot this adoption unnoticed — Appendix F requires the suite to keep compiling even when it
  does not execute. Verified rather than asserted:
  ok github.com/open-feature/go-sdk-contrib/providers/flagd/tck 0.175s [no tests to run].

An untagged guard in the module fails if nothing in it reaches tck.Run, because a conformance module
whose tests stopped running the suite leaves make tck green by running nothing.

What is not here

• flagd's file resolver. No backend to disconnect from, so it would use in-process control and a
  different capability set. Left out to keep the reviewable surface small.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}