docs(flagd): say what the new tags gate here, and what the testbed still owes

@Variants and @targeting arrived with the base's submodule bump, and
declarableExcept picks both up without a line of this file changing. That is the
right outcome and the reason nothing here said so, which is the problem: the
declaration grew by two capabilities and the file that argues every other one
either way was silent about them.

Two runs against flagd-testbed v3.8.0, one per resolver. RPC: 45 pass, 5
skipped, 2 failed. In-process: the same, after a first attempt whose opening
scenario timed out on a cold sync stream and passed on rerun -- a warm-up flake,
not a result. @targeting's three scenarios resolve targeting-key-flag through
flagd's own rule evaluation and pass in both modes on the image already pinned,
so the tag cost no bump; the Compose header now says so, because the note beside
that tag is where someone would otherwise go looking for a reason to bump it.

Both failures are the one testbed gap, and the @Variants outline reaches it a
second time: once for the untagged precision scenario, once for the row asking
for large-integer-flag's max-int32 variant. So the header's "one untagged
scenario" is a scenario short. Withholding @Variants would hide both -- and
would be a claim about flagd made to accommodate a missing flag, which is the
one thing a declaration must not be.

The capabilities() javadoc also still called @targeting reserved, in the
paragraph explaining why complementOf is the wrong call. It is declarable now,
and the paragraph is stronger for losing it: the reserved set shrinks as the
vocabulary fills up, so what protects the declaration is the form of the call
rather than the size of the set.

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

Author: aepfli

providers/flagd/src/test/java/dev/openfeature/contrib/providers/flagd/e2e/AbstractFlagdTckTest.java

@@ -163,11 +163,23 @@ public FeatureProvider createUnavailableProvider() {
      * fault for a value the accessor cannot carry. Its one scenario is reported as skipped for an
      * undeclared capability, like any other.
      *
+     * <p>{@link Capability#VARIANTS} and {@link Capability#TARGETING} are both declared, and both on
+     * evidence rather than by inheriting the "everything except" default. flagd names the variant it
+     * served in every resolution, so seven of the {@code @variants} outline's eight rows pass in both
+     * modes; the eighth asks for {@code large-integer-flag}'s {@code max-int32} and is answered with
+     * no variant because testbed v3.8.0 does not serve that flag at all — the same gap that fails the
+     * untagged precision scenario, recorded next to the image tag in the Compose file rather than
+     * here. {@code @targeting} is the newer claim and the cheaper one to check: its three scenarios
+     * resolve {@code targeting-key-flag} through flagd's own rule evaluation and all three pass in
+     * both modes on the image already pinned, so nothing about it needed a testbed bump.
+     *
      * <p>{@link Capability#declarableExcept} rather than {@code EnumSet.complementOf}, which is what
      * this used to be. The complement of one capability is every other <em>enum constant</em>,
-     * including {@code @targeting} and {@code @caching} — reserved tags no scenario carries — so
-     * declaring the complement claimed two capabilities nothing had examined, and the suite refuses
-     * such a declaration at startup.
+     * including {@code @caching} — a reserved tag no scenario carries — so declaring the complement
+     * claimed a capability nothing had examined, and the suite refuses such a declaration at startup.
+     * It swept up {@code @targeting} the same way until that tag gated something, which is the point:
+     * the hazard shrinks as the vocabulary fills up and never disappears, so the form of the call is
+     * what protects the declaration, not the current size of the reserved set.
      */
     @Override
     public Set<Capability> capabilities() {

providers/flagd/src/test/resources/tck/docker-compose.yaml

@@ -3,9 +3,14 @@
 # The image serves flagd itself and the "launchpad" control API on 8080, whose endpoints this
 # TCK's control API contract was derived from. It does not yet serve the whole canonical flag
 # set: v3.8.0 has none of large-integer-flag, huge-integer-flag or integral-float-flag. Only
-# large-integer-flag is reached by a scenario that runs here -- the other two sit behind
-# @large-integers and @numeric-coercion, which this provider does not declare -- so one untagged
-# scenario fails FLAG_NOT_FOUND until open-feature/flagd-testbed#392 lands. Bump the tag then.
+# large-integer-flag is reached by scenarios that run here -- the other two sit behind
+# @large-integers and @numeric-coercion, which this provider does not declare -- and it is
+# reached twice: the untagged precision scenario, which gets the code default instead of
+# 2147483647, and the @variants row that asks for its "max-int32" variant and is answered with
+# none. Both fail until open-feature/flagd-testbed#392 lands. Bump the tag then.
+#
+# targeting-key-flag is served, which is why @targeting needs no bump: its three scenarios pass
+# on this image in both modes.
 #
 # Note there are no host port bindings. The TCK requires dynamically mapped ports and discovers
 # them after startup — a pinned host port would make the suite unrunnable in parallel and would