Instrument connection, sync, settings, media, cache, features, and deactivation analytics events

[gabrielcld2]

Approach

Wires the remaining 7 event categories from the Analytics Event Tracking Spec POC's custom-events framework:
connection management, asset sync, settings & navigation, media & asset actions, non-media cache, extensions & gallery, and deactivation (30 events total).

No changes to the transport layer (Analytics::track() / Analytics.track()) — this is call-site wiring only.

Design decisions worth a second look

• bulk_sync_started only covers the manual REST trigger (Push_Sync::rest_start_sync()). The auto_restart case inside Sync_Queue::stop_maybe() is treated as internal plumbing and isn't instrumented.
• asset_sync_failed hooks the broad, already-generic Sync::log_sync_result() rather than the narrowerUpload_Sync::upload_asset(), trading a small asset_type lookup cost for covering every sync type in one place.
• sync_completed needed new state (Sync_Queue::mark_run_started() / tally_run_result() / track_run_completed()) since no
  existing signal survives the queue's internal restart cycles.
• account_switched is new comparison logic in Connect::verify_connection() — Connect::switch_account() turned out to be dead code (no callers since 2021), not something to hook into.
• Cache-category events target php/assets/class-rest-assets.php, not php/class-cache.php — the latter is never instantiated (dead code), confirmed via exploration before wiring anything.
• gallery_configured's layout/media_count are parsed out of the gallery_config field's serialized JSON blob rather than being real submitted fields.

Unrelated fix included: duplicate page-view bug

While QA'ing settings_page_viewed, we found it firing twice per single page load on Image Settings / Video Settings. Root cause: Image_Preview::preview() set the sample <img>'s src="#", which resolves to the current page's own URL — so the browser fired a second real request back at the same admin page (as an image fetch) before global-transformations.js replaced it with a real preview URL. Video_Preview and Breakpoints_Preview both extend Image_Preview and inherited the same bug.

This is a genuine, pre-existing perf bug unrelated to the analytics work, but it directly corrupted the accuracy of the new settings_page_viewed event on exactly the pages it affects, so it's fixed here rather than filed separately: src="#" → an inert 1x1 data-URI placeholder. Confirmed via raw Apache access logs (down to one request) and the capture log (down to one event) that the duplicate is gone; full Playwright suite still green afterward.

Unrelated fix included: attributes:class never applied on the link UI component

special_offer_clicked needed the special-offer <a> to render with a stable class, set via attributes:class on the link component's config. It never actually applied: Params_Trait::get_param() splits its path on ., so a colon-delimited key never matched the nested attributes array. Fixed in php/ui/component/class-link.php to read attributes directly. Confirmed no other caller relied on the broken fallback.

QA notes

28 of the 30 events in this PR are covered by automated e2e specs — run npm run test:e2e (one spec file per category: tests/e2e/{connection,sync,settings,media,cache,features,deactivation}-analytics.spec.js) and confirm it's green. That's the QA gate for everything except the two events below, which have no automatable trigger:

• connectivity_check_failed — cron-only (daily ping / REST-API self-check), no UI path exists. To check manually: connect with a valid Cloudinary URL, then break it (wp option update cloudinary_connect '{"cloudinary_url":"cloudinary://invalid"}' --format=json), run wp cron event run cloudinary_status --due-now, and confirm the event in the capture log (.wp-env/mu-plugins/analytics-capture.php, wp cloudinary analytics-events).
• account_switched — needs two real Cloudinary cloud names. Connect with account A's credentials via the wizard or Connect settings page, then submit account B's credentials on the same page; confirm the event carries previous_cloud_name/new_cloud_name.

Regression check: confirm no PHP notices/fatals in wp-content/debug.log and no new JS console errors while the suite runs — none of this should be visible to a site admin who isn't looking for it.