Prospects: a failed list read is said

PR #11609, audit gap G10. The captures are from a local dev server on the branch, bound to propflow-stage (anonymized by construction; checked through /api/health before the browser launched). They were signed in as the smoke user, and every list read (/api/leasing/prospects) was forced to answer 500 with Playwright's request routing.

1. A refresh fails over this selection's own rows

The page loaded normally, then every later read failed. The rows are this selection's last good load, so they stay. The line above the table says they are the last good load, so they are not passed off as current.

Prospects list with the line: We couldn't refresh this list. These are the leads from the last successful load; the page keeps retrying.

Checked in the DOM: “We couldn't refresh this list” present: True; table rows kept: 50.

2. Company switch, and the new company's read fails

This time the company picker switched to one company (a TEST company) while every read failed. None of the previous selection's rows stay. The table's title says the read failed and names the next thing that happens, and the count reads “—”. Before this PR it would have shown the old company's leads under the new name. Without the round-2 fix it would have shown “No prospects found.” and “0 prospects”. Both are claims about a list nobody read.

Prospects list, empty table titled: We couldn't load leads for this selection. The page keeps retrying every few seconds. Count shows a dash.

Checked in the DOM: “We couldn't load leads” present: True; “Clara will track leads as they come in.” present: False; table rows: 0.

Critique rounds

Round 1 found the empty state still titled “No prospects found.” with a “0 prospects” count over an unread list. Round 2 added a failure title, the next action as the detail, and countUnknown on the shared DataTable (renders “—”). The regression test now fails on the previous head for both strings.