Analytics: Snapshot the site into a value type at the tracking boundary

[jkmassel]

Building on #25882, this replaces the raw Core Data Blog at the analytics boundary with a Sendable value-type snapshot, so tracking never reads a managed object off its context's queue. It's the load-bearing first step toward extracting analytics into a module that takes no Core Data types.

Summary

• New BlogAnalyticsProperties value type + BlogAnalyticsRepresentable protocol in WordPressShared.
• Blog conforms in WordPressData, snapshotting on its context queue.
• The two site-attaching track boundaries read from the snapshot, not the live Blog.
• No call-site changes — Blog conforms, so existing track(…, blog:) calls compile unchanged.

Root cause

WPAnalytics.track(_:properties:blog:) read blog.dotComID and blog.isWPForTeams synchronously, on whatever thread the caller was on. Both are Core Data accesses:

• Blog.dotComID's getter can write back to the object — it back-fills blogID from jetpack.siteID.
• isWPForTeams faults the options relationship.

Reading either off the object's context queue is a threading violation. AnalyticsTrackerAutomatticTracks.getSessionInfo already wraps its Blog reads in context.performAndWait — the per-event path was the one place that didn't.

Changes

1. BlogAnalyticsProperties + BlogAnalyticsRepresentable (WordPressShared)

A Sendable struct carrying the two facts analytics needs — dotComID and isWPForTeams — and a protocol that vends it. Only this value crosses the model boundary.

2. Blog: BlogAnalyticsRepresentable (WordPressData)

analyticsProperties reads the two fields inside managedObjectContext.performAndWait, so the snapshot is safe to hand to analytics from any thread. Conformance lives with the model — not retroactive.

3. Boundary functions read the snapshot (app target)

• WPAnalyticsEvent.swift: split into a value-type core track(_:properties:blogProperties:) and a track(_:properties:blog: some BlogAnalyticsRepresentable) convenience that snapshots. The @objc trackEvent(…blog: Blog) and trackBlockEditorEvent forward through it, unchanged.
• WPAppAnalytics+Extensions.swift: track(_:properties:blog:) reads blog.analyticsProperties instead of touching dotComID / siteType(for:) directly.

Not in this PR

• The module. This is the boundary type. Moving WPAnalyticsEvent, BlogDashboardAnalytics, and the trackers into a standalone WordPressAnalytics package (depends on WordPressShared, not WordPressData) is the follow-up — now unblocked, because the per-event Core Data dependency is severed. AnalyticsTrackerAutomatticTracks stays app-side (it's injected via registerTracker), so the module won't need Blog.count(in:) / hasAnyJetpackBlogs.
• The domains and post paths. WPAnalytics.domainsProperties(for: blog) (reads canRegisterDomainWithPaidPlan) and WPAppAnalytics.track(_:properties:post:) still take Core Data types. Same treatment, separate PRs.

Test plan

• WordPress scheme builds clean — 0 errors.
• BlogAnalyticsPropertiesTests passes (WP.com / P2 / self-hosted).
• Sign in, open My Site, and confirm my_site_dashboard_card_shown still logs blog_id / site_type for every card (behavior unchanged from Analytics: Attach the selected site to My Site dashboard card impressions #25882).

Related

• Builds on Analytics: Attach the selected site to My Site dashboard card impressions #25882
• CMM-2213

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	33718
	Version	PR #25883
	Bundle ID	org.wordpress.alpha
	Commit	e5a3fe2
	Installation URL	44mr5lkab47ho

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	33718
	Version	PR #25883
	Bundle ID	com.jetpack.alpha
	Commit	e5a3fe2
	Installation URL	7c62tlqaahg5o

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.

[crazytonyli]

I don't think the "never run off-queue" comment is necessary. The theory is correct, but it does not apply in this context, because the code calls blog properties, and, if it's off-queue, this code does not prevent that.

[jkmassel]

Addressed in f4f3212