Architecture explanation, developer how-to guide, editor
filters reference, and make/core announcement draft for the
client-side media processing feature shipping in WP 7.0.

- Fix wasm-vips links to point to canonical kleisauke/wasm-vips repo
- Add wp_ prefix to filter name in feature-detection docblock
- Use wp.apiFetch instead of hardcoded /wp-json/ path in sideload example

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Document the finalize REST endpoint, editor.media.imageQuality
JS filter, and server-side hook compatibility added in PR #74913
across architecture, how-to, and Make Core post docs. Also fixes
a typo ("eprocessing") in the Make Core post.

The feature shipping target moved from 7.0 to 7.1 (per #76756). Bring
the architecture explanation and how-to guide up to date with the
post-7.0-cycle state of the code:

- Reposition introductions around 7.1 with 7.0 as the groundwork cycle.
- HEIC/HEIF: document the canvas-based fallback path (createImageBitmap,
  HTMLImageElement+OffscreenCanvas, HEIC container parsing + WebCodecs
  VideoDecoder), JPEG companion file, and isHeicCanvasSupported() gate.
- AVIF: note the wp_prevent_unsupported_mime_type_uploads bypass when
  generate_sub_sizes=false (#76371).
- Batch thumbnail generation via image.copyMemory() / thumbnailImage()
  (#76979).
- Sub-size deduplication via image_size: string|string[] on the sideload
  route (#77036).
- Single VIPS instance via promise caching (#76780).
- Build-output trimming: remove vips-jxl.wasm (#76639), skip non-min
  worker (#76615), skip WASM-inlined sourcemaps (#75993).
- COI: <img> excluded from cross-origin attribute injection (#76618).
- Loosened feature-detection thresholds: 2 cores, 3g (#76616).
- Post-saving lock fix: Save Draft now respects the lock (#76973).
- convert_format declared as boolean on sideload route (#77565).
- Fix incorrect REST index settings list (only image_sizes and
  image_size_threshold are exposed).
- Remove references to client_side_supported_mime_types filter
  (PR #76549 was closed unmerged); state the supported MIME set is
  fixed at CLIENT_SIDE_SUPPORTED_MIME_TYPES.

Refs #75111.

The feature ships in 7.1 instead of 7.0 (per #76756). Reframe the post
as a 7.1 announcement with a dedicated 'What's new in 7.1' section
listing HEIC support, end-to-end AVIF uploads, batch thumbnail
generation, sub-size deduplication, single VIPS instance, save lock
fix, loosened device requirements, <img> COI exclusion, smaller build
output, and the convert_format boolean coercion fix. Each item is
linked to its merged PR.

Move the original 7.0 cycle deliverables under 'What changed during
7.0' so the historical context stays available for the announcement
audience.

Update technical overview to use the actual function name
(gutenberg_is_client_side_media_processing_enabled), reflect that
DIP replaces COEP/COOP, and remove the inaccurate note that the
imageQuality hook isn't wired up.

Drop the make-believe client_side_supported_mime_types filter; PR
#76549 was closed unmerged. State that the supported MIME set is
fixed at CLIENT_SIDE_SUPPORTED_MIME_TYPES.

Update browser compatibility table to reflect the DIP-based gating
(Chromium 137+, no Firefox/Safari) and add a feature detection
thresholds section.

The handbook generator derives slugs from filename basenames, so
docs/how-to-guides/client-side-media.md and
docs/explanations/architecture/client-side-media.md collided on the
slug "client-side-media" and broke docs:gen in CI.

Rename the architecture file to client-side-media-architecture.md and
update all internal cross-references plus the public-URL references in
the Make/Core draft post.

Run docs:build to add manifest entries for the new how-to guide and
architecture explanation pages, fixing the check-local-changes CI step.

Adds a Frequently Asked Questions section addressing common public
misconceptions raised on issue #76756 — bandwidth-vs-CPU/RAM framing,
the 'never trust the client' security objection, fallback behavior,
hook compatibility, format conversion, and browser support.

…client-side media docs

The filter actually fires twice during a client-side upload — once
with context 'create' during the initial upload (WP core's
wp_generate_attachment_metadata() runs even when
intermediate_image_sizes_advanced is filtered to empty) and again
with 'update' at finalize. Earlier wording suggested the filter
was bypassed initially and only ran at finalize, which is wrong.

The double-fire pattern matches how WordPress already handles
big-image uploads on the server, where sub-size generation is
deferred and triggers a second 'update' pass. Frame the contract
that way across all three docs and tell plugin authors to be
idempotent — there's nothing new for them to handle that they
haven't already accommodated for big-image uploads.

Other corrections in the same pass:

- Soften the "security model is unchanged" FAQ in the make/core
  post: AVIF uploads from the client-side path do bypass
  wp_prevent_unsupported_mime_type_uploads when generate_sub_sizes
  is false, which is a deliberate exception worth surfacing.
- Fix HEVC fallback wording in the how-to guide (Chrome 107+ on
  macOS → Chromium 107+ via the platform codec, covering Windows
  HEVC Video Extension as well).
- Note Safari's HEIC canvas fallback in browser-support tables
  across all three docs (architecture and how-to guide both said
  flat "Not supported").
- Add packages/vips/src/worker.ts to the source-files list — it's
  the actual entry point loader.ts dynamically imports.
- Align image quality figure to "0–1, default 0.82" everywhere
  (architecture doc had "82%").
- Drop residual historical PR link in the how-to guide
  troubleshooting table (#76973 Save Draft fix).
- Drop the "graduated from a Gutenberg experiment" version-history
  framing from the architecture doc and make/core post.
- Drop the historical 7.0 iteration link from the make/core post
  related-tracking-issues list.

…ype set

Add a "See also" footer to the architecture doc pointing to the
how-to guide and the editor-filters reference, so plugin authors
who land on the architecture page have an obvious next step toward
actionable guidance.

Add a callout in the editor-filters reference noting that
CLIENT_SIDE_SUPPORTED_MIME_TYPES is fixed and not exposed via a
filter. Plugin authors looking for a "supported types" filter will
land in the filter reference first; documenting the absence
prevents a hunt that the make/core post and how-to guide already
mention but the reference itself didn't.

- Split the long lede sentence in the make/core post explaining
  the finalize 'update' pass into two sentences for readability.
- Cross-reference the security-FAQ MIME-bypass detail from the
  AVIF Key benefits bullet so readers connecting "accepts AVIF"
  to "how" can find the explanation in one click.
- Update the architecture upload-flow Mermaid label to
  "wp_generate_attachment_metadata context: 'update'" so attentive
  readers don't infer the filter only fires at finalize.
- Move the dense parenthetical in the how-to guide finalize
  section into a trailing sentence, keeping the cross-link to
  the server-side compatibility section.

Add a Requirements section near the top of the how-to guide covering
browser support, required browser capabilities, and device/network
thresholds (>2GB RAM, >=2 cores, faster-than-2g). The system thresholds
were previously only discoverable by scanning the troubleshooting table.

Remove the now-redundant trailing Browser compatibility section, which
the new section subsumes.

- Note automatic retry with exponential backoff for resilient uploads (#76765)
- Reframe cross-origin isolation as a capability (SharedArrayBuffer) extenders can use, not an implementation detail
- Clarify that Firefox/Safari are unsupported for the full pipeline, with a pointer to the compatibility section
- Add publication-date browser-version context and a Chrome Platform Status link for tracking Document-Isolation-Policy support
- Fix the Safari compatibility row wording and stray parenthesis
- Merge the duplicated 'Feature detection thresholds' and 'Known limitations' sections into one
- Explain why the AVIF MIME-check exception carries minimal security risk