Fresh local dashboard blocks on WordPress.org checks

## Summary

Fresh Studio local sites synchronously call WordPress.org during the first wp-admin dashboard render. This makes `/wp-admin/` feel slow even though the site is local.

## Evidence

Using the Homeboy WordPress request profiler against an isolated Studio test worktree:

Baseline fresh dashboard:

- `/wp-admin/` PHP request: ~1608ms
- Curl total: ~2.24s
- Outbound WordPress.org calls: 5
- Slow spans:
- `admin_init`: ~75ms -> ~916ms
- `admin_enqueue_scripts`: ~1526ms

Observed outbound calls on first dashboard:

- `https://api.wordpress.org/core/version-check/1.7/…`
- `https://api.wordpress.org/plugins/update-check/1.1/`
- `https://api.wordpress.org/themes/update-check/1.1/`
- `https://api.wordpress.org/core/browse-happy/1.1/`
- `https://api.wordpress.org/core/serve-happy/1.0/…`

Experiment removing update checks and seeding local-safe Browse Happy / Serve Happy transients:

- `/wp-admin/` PHP request: ~150ms
- Curl total: ~0.75s
- Outbound WordPress.org calls on dashboard: 0
- Repeat sample stayed ~150ms

Homeboy browser benchmark against the experiment:

- Passed
- `dashboard_domcontentloaded_ms`: ~1426ms avg
- `dashboard_heading_visible_ms`: ~1444ms avg
- `dashboard_widgets_visible_ms`: ~1448ms avg
- Previous comparable dashboard run was ~2880ms, so roughly half the user-visible load time.

## Regression risk from broad experiment

A broad MU-plugin experiment is too blunt as a final fix:

- It globally removed `_maybe_update_core`, `_maybe_update_plugins`, and `_maybe_update_themes` on `admin_init`.
- Broad probes showed Plugins, Themes, Updates, Add Plugins, Add Themes, and Site Health still returned 200, but that does not prove no regressions.
- Explicit update-management pages should likely keep normal WordPress.org update behavior because those pages imply user intent.
- Removing `dashboard_primary` changes visible dashboard content and should not be part of a purely performance-oriented fix without product approval.

## Preferred direction

Implement a dashboard-scoped fix:

- Target the first dashboard path only (`/wp-admin/` / dashboard screen).
- Do not change explicit update-management pages like `plugins.php`, `themes.php`, `plugin-install.php`, `theme-install.php`, or `update-core.php`.
- Avoid removing dashboard content unless separately approved.
- For local Studio dashboard requests, suppress/defer remote checks that do not add useful local-dev value:
- core/plugin/theme update checks triggered during first dashboard load
- Browse Happy
- Serve Happy

## Acceptance criteria

- Fresh dashboard no longer blocks on the listed WordPress.org calls.
- Dashboard still renders successfully.
- Explicit Plugins/Themes/Updates/Add pages still load and retain normal API behavior.
- Site Health still loads.
- A targeted benchmark/profiler run shows the dashboard request no longer performs outbound WordPress.org checks.

## AI assistance

- **AI assistance:** Yes
- **Tool(s):** OpenCode (GPT-5.5)
- **Used for:** Profiling, evidence summarization, and issue drafting under Chris Huber's direction.