Clean up build-strategy/metadata docs and help text; document one-platform-per-invocation constraint

[ianpittwood]

Context

The spike (#728) established that --strategy bake and --strategy build emit the same
metadata contract, and #733 makes --metadata-file work on the bake path. Several docs and
help strings still assert the old, strategy-specific story, and one important behavioral
consequence of the metadata format is documented nowhere.

Known doc issues to fix

• plugins/builtin/imagetools/imagetools.py:206 — imagetools merge help says the input is
  "build metadata JSON files (produced by bakery build --strategy build)". Post-feat: carry --metadata-file through the bake build strategy #733 this is
  actively misleading; either strategy produces valid input. Reword to
  "produced by bakery build --metadata-file (either build strategy)".
• cli/build.py --metadata-file help ("The path to write JSON build metadata to once builds
  are finished") does not mention that the file is keyed by image-target UID, nor that with
  --strategy build it is written only after all targets succeed while with
  --strategy bake buildx owns the file. Document the write semantics, since a failed target
  means downstream dgoss run / ci publish see a missing (bake) vs. absent (build) file
  rather than a partial one.
• cli/build.py --plan is bake-only and errors out under --strategy build
  (cli/build.py:281-291); the help text does not say so.
• --jobs help mentions it is ignored for --strategy bake, but the surrounding strategy
  docs don't summarize the strategy differences anywhere a user would find them. A short
  "choosing a build strategy" section (parallelism, --plan, --fail-fast scope, metadata
  write semantics) in CONTRIBUTING.md or the bakery README would consolidate this.
• BakePlan.build()'s metadata_file docstring is currently the only place that records
  "one entry per bake target, keyed by the image target UID" — that fact belongs in
  user-facing docs, not just a docstring.

Multi-platform invocation consequence (document explicitly)

For both strategies, a target built for more than one platform in a single invocation
produces one metadata entry describing an index/manifest-list descriptor with no
platform field. BuildMetadata.platform (image/image_metadata.py) then returns None,
which means:

• ImageTarget.image_reference(platform=...) (image_target.py:498-512) finds no
  platform-matching metadata and falls back to a tag-based reference, so
  bakery dgoss run --metadata-file stops testing the exact built digest.
• ImageTarget.get_merge_sources() (image_target.py:742-757) collapses to a single source
  keyed on None, so per-platform merge inputs are lost.

Practical rule to write down: one platform per bakery build invocation when the metadata
file is going to be consumed by dgoss run or ci publish. This is what
bakery-build-native.yml already does (one image/version/platform per runner) and what
bakery-build.yml's QEMU path must keep in mind. This constraint predates and is unaffected
by the bake migration, but it has never been documented.

Acceptance criteria

• No remaining doc or help text implies metadata files are --strategy build-only.
• Strategy differences (parallelism, --plan, metadata write semantics) documented in one
  discoverable place.
• The one-platform-per-invocation constraint and its two concrete consequences are documented
  alongside the --metadata-file option.