fix(test-timer): slow timer notification reappearing after new test (@J-Karthikeyan)

[J-Karthikeyan]

Description

When a test fails due to the slow timer, the error notification ("Stopping the test due to bad performance...") has no auto dismiss timeout so it stays in the notification store indefinitely so it reappears once the next test is completed.

When we start a new test, the notification gets visually hidden by focus mode (non important notifications get a hidden class when getFocus() is true). When the test ends, focus mode turns off and the notification reappears making it look like it fired again when it didn't.

Steps to Reproduce

1. Start a test and let the slow timer trigger the notification by just typing one or two letter and leaving it.
2. Do NOT dismiss the notification
3. Start and complete a new test without a page refresh
4. The notification reappears at the end of the new test

Fix

Fix: track the error notification's ID when the slow timer fires, and remove it from the store when a new test starts via TestTimer.start().

[Copilot]

Pull request overview

Fixes a UX issue in the frontend test flow where a “slow timer” error notification could persist in the notification store and reappear after later tests, even though it wasn’t re-triggered.

Changes:

• Track the notification ID produced when the slow timer failure fires.
• Clear any previously-created slow-timer error notifications when a new test starts.
• Update notification helpers to return the created notification ID (to enable targeted removal).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
frontend/src/ts/test/test-timer.ts	Tracks slow-timer error notification IDs and removes them at TestTimer.start() to prevent reappearing stale errors.
frontend/src/ts/states/notifications.ts	Returns notifId from addNotificationWithLevel and selected convenience helpers so callers can later remove specific notifications.

Comments suppressed due to low confidence (1)

frontend/src/ts/states/notifications.ts:193

• Return types now differ across convenience helpers: showNoticeNotification/showErrorNotification return notifId, but showSuccessNotification stays void. This makes the API inconsistent and can create awkward unions when selecting a helper dynamically. Consider returning notifId from showSuccessNotification too, or keep all show* helpers void and expose a separate "add..." API for callers needing the id.

export function showNoticeNotification(
  message: string,
  options?: AddNotificationOptions,
): number {
  return addNotificationWithLevel(message, "notice", options);
}

export function showSuccessNotification(
  message: string,
  options?: AddNotificationOptions,
): void {
  addNotificationWithLevel(message, "success", options);
}