feat: add a network-wide presence summary table

[josephfusco]

Part of the network presence stack, merged bottom-up:

1. feat: add a network-wide presence summary table #332 summary table (this one)
2. feat: push each site's online set into the network summary #333 write path
3. feat: read the network summary as a capped snapshot #334 read path
4. feat: add an Online column to the Network Sites list #335 Sites list column
5. feat: add an Online view and column to the Network Users list #336 Users list
6. feat: add a Who's Online widget to the Network Admin dashboard #337 network dashboard widget

---

Reading who is online across a network means reading every site's presence table, and there is no way to do that from one site without switching into each of them.

Part of #298
Closes #326

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5, Claude Opus 5
Used for: Assisting with design, implementation, and testing

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props joefusco.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

▶ Preview in WordPress Playground

Boots a fresh WordPress with this PR's presence-api build, seeds 5 demo users, and drops you on the dashboard.

_{Stress-test variant: 40 demo users · Built from aa266e2e455cf1992f94155eafb46d7a88dbb2db. Auto-updates when you push.}

[codecov]

Codecov Report

❌ Patch coverage is 91.11111% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.99%. Comparing base (c29b700) to head (aa266e2).

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #332      +/-   ##
============================================
- Coverage     97.13%   96.99%   -0.14%     
  Complexity      190      190              
============================================
  Files            14       15       +1     
  Lines          2059     2098      +39     
============================================
+ Hits           2000     2035      +35     
- Misses           59       63       +4     

Flag	Coverage Δ
multisite	96.99% <91.11%> (-0.14%)	⬇️
phpunit	94.32% <6.66%> (-1.69%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[josephfusco]

Carried over from the review on #299, which this pull request replaces the schema half of.

Nothing ever removes a row

There was no wp_uninitialize_site or wp_delete_site hook, so a deleted site's row stayed forever. The read path skipped it because get_site() returned null, so it was a leak rather than a correctness problem.

uninstall.php also never dropped {base_prefix}presence_network_summary and never deleted wp_presence_network_summary_db_version or wp_presence_network_summary_table.lock.

Filed as #326, which this pull request claims to close, so the wp_delete_site hook and the uninstall.php additions are what to check.

Smaller

wp_presence_register_network_summary_table() appends to ms_global_tables with no in_array guard and runs both at require time and on init priority 0, so the entry lands twice. Filed as #330, not fixed here.

[josephfusco]

Merge order note, since the stack cannot go in as-is.

CI and CodeQL filter pull_request to branches: [ main ], so #333 through #337 run 4 checks each against the 17 here. #340 removes the filter.

For a pull_request event GitHub reads the workflow file from the merge commit, so merging #340 into main is not enough on its own; each stack branch has to carry it. Sequence:

1. Merge ci: run CI and CodeQL on pull requests that do not target main #340.
2. Rebase this branch onto main, then each branch above it onto its parent, bottom-up, pushing with --force-with-lease.
3. Full CI then runs on all six, and they merge bottom-up from here.

Nothing else in the stack is waiting on anything.