fix(frontend): badge trigger is not exposed as a button (audit finding 3)

[Shaan-alpha]

Scope narrowed after browser verification. This PR started as findings 2 and 3 from the audit in #59. Finding 2 turned out not to be a real bug — verified against Chrome and reverted in the second commit. What ships here is the a11y fix only. History kept rather than squashed, because the negative result is the useful part.

What ships: the badge trigger was not a button (finding 3)

The trigger renders through Badge, which is a <span>. Base UI defaults nativeButton to true, so it put type="button" on a span and left the element with no role at all.

Confirmed in real Chrome via the accessibility tree, not just the attribute:

	role attr	Chrome AX tree role
main	null	generic
this PR	button	button

generic means the evidence behind every badge was unreachable to a screen reader. The comment above the component claimed "Popover.Trigger renders a <button>" — a Base UI upgrade made that false at some point. Base UI has been warning about it at runtime the whole time (expected a native <button> because the nativeButton prop is true); the warning is even in the known-noise list in .claude/skills/verify, so it was being actively ignored rather than missed.

nativeButton={false} tells Base UI the truth, and useButton then applies role="button" plus the non-native keyboard handling. Confirmed against the Base UI docs rather than guessed.

What got reverted: the Activity popover leak (finding 2)

The audit's jsdom probe suggested that because Popover.Portal mounts into document.body — outside the <Activity> boundary — a popover pinned open when the user hits browser-back would stay painted over the next route. I wrote a fix for it. Real Chrome says there is no such bug.

The first probe run was itself wrong and worth flagging: it used Page.navigate to reach the report, which is a full document load, so "back" tore the document down and the popup was trivially gone on every branch. That proved nothing. Re-driven properly — land on /, navigate client-side through the app's own search bar so the App Router keeps / alive in an Activity boundary, pin a popover, then history.back():

main (unfixed), after browser-back:
  popup_after_back: { present: true, w: 0, h: 0,
                      hiddenAncestor: true, painted: false }

React's display: none does reach the portal in a real browser. The popup is already not painted without any fix. happy-dom's portal handling differs from Chrome's, and that difference is the whole of the original "evidence."

So the fix bought nothing and cost controlled Popover.Root state, a useLayoutEffect, direct DOM manipulation of the positioner, and an eslint-disable. Reverted.

The vitest suite now has no <Activity> test for this component, with a comment explaining why — a test that only fails under happy-dom is asserting the test environment, not the product.

Verification

vitest run 76 passed / 24 files, tsc --noEmit clean, eslint src clean, plus the CDP run above against both branches.

Console errors during the run were unchanged from the known-noise set (getServerSnapshot, uncached-promise suspension) with one difference in this PR's favour: the Base UI nativeButton warning is present on main and absent here.

Not drivable locally, so not claimed either way: signed-in and /share/{slug} variants (no DATABASE_URL/OAuth in backend/.env).

Merge order

CI here stays red on Backend until #60 merges — main is red from a fixture time bomb unrelated to this. No file overlap with #59, #60, #61 or #63. CHANGELOG/PROGRESS_LOG entries for the batch are consolidated in #59.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.