a11y: check whether DismissibleHint's `role="note"` has the same async-insert problem fixed in #129

[pitimon]

What

dashboard/src/ui/components/DismissibleHint.jsx:55 sets role="note".

#129 changed the same attribute on IngestHealthNotice to role="status" + aria-live="polite",
because that notice is inserted after an async fetch resolves — no user action, no focus move — so
a static note landmark is announced only if the user happens to navigate onto it.

Whether DismissibleHint shares that property is unchecked. If it renders synchronously with
its parent, role="note" is correct and this issue closes as no-change. If it appears in response
to data arriving or state changing after mount, it has the same problem.

Why it is filed rather than fixed

It surfaced during a blast-radius grep on #129 (grep -rn 'role="note"' dashboard/src), which is
the right way to find it and the wrong moment to change it — it is a different component with
different mount semantics, and #129 has no test coverage for it.

To resolve

1. Determine whether DismissibleHint can appear after its parent has mounted.
2. If yes: role="status" + aria-live="polite", and a test asserting the live-region attribute
   separately from the role — IngestHealthNotice.test.jsx:83 is the pattern. The role alone is
   what regressed in the case that prompted this.
3. If no: close with that reasoning recorded, so the next grep does not re-open the question.

Context

#129 (comment)

[pitimon]

Checked: it IS async-inserted — but the fix from #129 probably should not be copied here

The factual question

DismissibleHint is rendered from one place, dashboard/src/pages/SkillsPage.jsx:1361, behind:

!manageOpen && !isSkillsSh && !isPopular && repos.length <= 1 && browseItems.length > 0

browseItems is a useMemo (SkillsPage.jsx:1133) over fetched skills state — there is a
browseBusy loading flag guarding the same region at :1279. So the hint appears after data
arrives, not synchronously with its parent. The premise of this issue holds: it is inserted
asynchronously, exactly like IngestHealthNotice was.

Why I would still leave it as role="note"

The two cases differ in what the insertion means, not in when it happens:

• IngestHealthNotice is a warning about something going wrong that the user cannot otherwise
  see — tokens silently not being counted. A user who cannot see the amber box has no other route
  to that information, which is what made the missing announcement a real defect.
• This is a supplementary hint next to content the user just asked for. It appears at the same
  moment the browse results appear, in the region the user is already about to read, and it says
  "you can add a repo". Announcing it would interrupt to deliver something the user reaches anyway
  by reading on.

Turning it into a live region means every skills-page load with one repo configured announces the
hint. That is the noise failure mode of aria-live, and it makes the announcements that do
matter cheaper to ignore.

Recommendation

Close as no-change, with the reasoning recorded so the next grep -rn 'role="note"' does not
re-open it — which is what this issue asked for as its third option.

If someone disagrees, the middle option is to keep role="note" but ensure the browse-results
region itself is announced when it finishes loading, so the hint arrives inside an already-announced
context. That is a SkillsPage change, not a DismissibleHint change.

Evidence

Read SkillsPage.jsx:1133, :1279, :1361-1373 and DismissibleHint.jsx:55. Not verified in a
browser with a screen reader — the async-insert claim comes from the render condition, and the
judgment above is a design call rather than a measurement.