a tab badge reads 0 when the count is unknown

[kensac]

Objective

The open-source-requests tab badge on /job-scripts/sources shows 0 when the count is unknown, not only when it is genuinely zero. Make an unknown count render as unknown.

Reason

app/job-scripts/sources/page.tsx:380 (personal-portfolio) reads the count and swallows every failure:

fetch('/job-scripts/api/catalog?requests=open', { cache: 'no-store' })
  .then((r) => (r.ok ? r.json() : Promise.reject()))
  .then((d) => setOpenRequests(Array.isArray(d.requests) ? d.requests.length : 0))
  .catch(() => {})

openRequests initialises to 0 and the catch leaves it there, so a failed read is indistinguishable from "nothing is waiting". Three paths produce the same 0: a non-ok response, a thrown request, and a 200 whose body is not the expected shape.

"No source requests are waiting" is a claim about a queue an admin acts on. docs/agents/frontend.md in this repository is explicit that a failure must never render as an empty result, because empty means "there is nothing" and error means "we could not find out", and the reader cannot tell them apart.

This was found while sweeping that class in personal-portfolio#343, which fixed five reads-rendered-as-data and three writes-reported-as-success across both surfaces. It was deliberately left out of that PR and is recorded here rather than dropped.

Why it is not a one-liner

Every other site in that sweep could hold a separate somethingFailed boolean and render an error in place of its content. This one is a number inside a tab label, and the tab component has no way to express "unknown". The fix is to teach it one — a count of number | null with its own rendering for null — and then convert the call site. That is a shared-component change with other call sites to check, which is why it did not belong in an error-state PR.

app/job-scripts/components/budgets-tab.tsx already does the equivalent correctly for a boolean: boolean | null, control disabled while null, its own copy for that case. That is the pattern to follow.

Requirements

1. The tab badge distinguishes "0 waiting" from "could not load the count".
2. The distinction lives in the tab component, so other counted tabs inherit it rather than each solving it again.
3. The three failure paths above all reach the unknown state, not just the thrown one.

Passing criteria

• With the catalog request failing, the sources tab does not read 0.
• With the request succeeding and no open requests, it still reads 0.
• A 200 carrying an unexpected body reaches the unknown state rather than 0.
• No other counted tab regressed; the count stays a plain number where the read cannot fail.

Not verified

• How many other counted tabs share the component, and whether any of them already guard this. Only the sources one was read.
• Whether the catalog endpoint fails in practice. The defect is that the display cannot express the failure, not that the failure is common.