feat(plugins): render contentAccess tables in the install consent dialog

[mostafasadeghidev]

What changed

The plugin install/upgrade consent dialog rendered requested permissions and networkAllowedHosts but silently omitted the manifest's contentAccess[] per-table allowlist — even though the SDK docs claimed the consent screen showed it. An operator could approve a plugin without ever seeing which content tables it may read or write. This adds a "Content tables" section mirroring the existing "External hosts" section.

• New diff helper (computeContentAccessDiff.ts): diffs entries by table into new / existing / dropped rows on upgrade, with the same ordering and badges as the host diff. One deliberate extension: an already-approved table whose upgrade adds modes (e.g. read → read, write) is promoted to "new" and the row calls out the newly requested modes — a silent privilege expansion cannot hide behind an "Already approved" badge.
• Rendering (PermissionReviewSection.tsx): each row shows the table slug in code style with its modes ("Read, write"). The @own-created marker renders human-readably as "Tables this plugin creates" instead of a literal slug — forward-compatible: marker rows appear only once the marker's parser change lands (separate PR).
• Plumbing: usePluginsWorkspace threads previousContentAccess from the installed plugin's manifest, exactly like previousNetworkAllowedHosts.
• Styling: the network-specific CSS classes became shared .allowlistSection / .allowlistHeader; dropped rows now strike through <code> labels too — which also fixes dropped host rows, which previously had no strikethrough. All tokens, CSS Modules only, no new colors.
• Docs: consent-screen description in plugin-system.md, the contentAccess doc comment in the SDK manifest types, and the PLUGIN-001 e2e row.

Why

contentAccess is a security surface: it is the per-table allowlist the host enforces on every cms.content.* call. Consent that hides it asks the operator to approve access they cannot see.

Impact

Operators see exactly which tables a plugin wants, with per-mode diffing on upgrades. No behavior change for plugins; UI only.

Tests

9 new tests in permissionReviewSection.test.tsx: 5 unit tests for the differ (including the mode-expansion promotion) and 4 render tests (marker row, upgrade badge/callout path). 23/23 pass.

Verification

bun run build   # tsc -b && vite build — clean
bun run lint    # clean
bun test        # touched suites green

Remaining full-suite failures are pre-existing on this machine — verified by stashing the diff and rerunning: the failure list is byte-identical without these changes.