bake: use singular keys for --set overrides

[crazy-max]

• needs bake: fix override value parsing #4088
• fixes [Bake] Inconsistency between --set and HCL for target platform(s) #2870
• supersedes and closes bake: accept "platforms" as alias for "platform" in --set overrides #3754

Singular names are now canonical for --set override selectors, while existing plural spellings remain supported as compatibility aliases. This makes platform and platforms interchangeable and applies the same convention to other collection and map selectors. The documentation distinguishes override selectors from Bake definition attributes and explains exceptions such as context versus contexts.<name> and secret versus secret.<id>.

[tonistiigi]

Agent suggestions:

Follow-ups (not blocking this PR)

All of these already exist on master. They turned up while reviewing, but they don't belong in this change.

1. Mixing = and += for the same key drops the replacement

Whichever --set comes last decides whether the whole list replaces the target value or appends to it (bake.go#L715, #L721).

target "app" {
  tags = ["orig/tag"]
}

--set	Result
app.tags=a app.tags+=b	[orig/tag a b]: = is ignored
app.tags+=a app.tags=b	[a b]

With this PR, the same happens when mixing aliases (app.tags=a app.tag+=b).

One possible rule: values repeated for a key still combine, but they append only if every one used +=. Otherwise they replace. That is a behavior change, so it needs a compatibility and release decision. The docs would also need to say that annotation, entitlement and attest always append whichever operator is used.

2. Wrong error text for secret and ssh parse errors

Both wrap the error as invalid value for outputs (#L1312, #L1325). It should name secret and ssh.

3. Broken --set docs example

buildx_bake.md#L435 shows --set foo*.no-cache, which fails:

invalid override foo*.no-cache, expected target.name=value

A value has always been required for every key except args (true since 6634f1e), so the example should be foo*.no-cache=true.

4. Unknown keys are ignored for targets that aren't built

After this PR, newOverrides rejects bad subkeys for every matched target, but unknown keys are still only checked in AddOverrides for targets that are actually built:

$ docker buildx bake app --set other.tag.foo=1   # error: tag does not support subkeys
$ docker buildx bake app --set other.bogus=1     # silently ignored

newOverrides now lists every valid key, so its default: branch (#L766) could reject unknown keys right away. The check could also run once before expandTargets instead of once per matched target.

5. One alias table for newOverrides and AddOverrides

AddOverrides is exported and accepts both singular and plural keys (#L1245 and others). A direct Go caller that passes both tag and tags gets a result that depends on map order. --set is not affected, because newOverrides normalizes the keys first.

A shared map[string]string of aliases, applied in both functions, would remove the duplicated alias lists and make the direct-call behavior deterministic.

[crazy-max]

@tonistiigi On item 5 is that a shared alias map removes the duplicated mappings, but normalization alone doesn't make AddOverrides deterministic when both spellings are present. The normalized keys still collide while iterating an unordered map. I think the smallest safe rule is to canonicalize the input first and reject conflicting raw keys rather than invent merge precedence for direct callers.

I also found one related pre-existing case: += is silently accepted for scalar and map-subkey overrides such as no-cache, arg.FOO, and label.foo, where it behaves exactly like =. That should be handled separately because rejecting it changes currently accepted input.