This introduces stateful filtering logic (healthFilter, filteredTables, filteredViews, unhealthyCount) with no tests. The hard rule for web-console: any behavior change needs tests.

numConnectorsWithProblems (systemErrors.ts) and the filtering logic here are pure functions -- easy to cover with Vitest + @testing-library/svelte. At minimum:

• isUnhealthy: does it correctly identify Unhealthy vs other statuses?
• filteredTables/filteredViews: does filtering by 'unhealthy' correctly exclude healthy connectors?
• numConnectorsWithProblems: does it count unhealthy connectors in addition to error counts?

This seems unrelated to this PR.

This change is required for a successful generation of OpenAPI bindings - the OpenAPI spec was referencing this new struct, but the struct itself was missing.

is the health optional because of backwards-compatibility?
In this case you could have a TODO to remove the null eventually.

It is optional in the API, so reflected as such in TypeScript

From the images given as part of the PR I didn't guess that there is actually a selector between "all" and "unhealthy". I don't know if there's a better way to show this visually. A combo box would work, but wouldn't make it clear that there are only two choices. Maybe a slider with two positions and one label only (all/unhealthy)?

I suspect we may have multiple different criteria we may want to filter connectors on; we have other instances of this selector UI component in the web-console: dark theme switch, selector on the Demos page, in the new Connector Errors list, and a few in mobile mode.

I would call this tablesFilteredByHealth

Again, health status may be one of multiple things we may want to filter on in the future

what is .filter(Boolean)?

It passes Boolean built-in function as a filter condition - it converts the argument value to bool based on JS's nullish-ness. In effect, this filters out empty descriptions.

I didn't know that Boolean is a built-in function, I think writing it as a lambda would be clearer

Well there are three candidates:

1. .filter(Boolean) - we covered that; and Boolean passed as a .filter() argument implies it has to be a function
2. .filter(v => v) - explicit lambda, concise, and still has an implicit "nullish"-check - this is the built-in JS behavior of casting values to bool
3. .filter(v => nonNull(v) && v !== "") - fully explicit, uses nonNull helper; I can change the condition to this, but this just re-impements the nullish check.

I assume you prefer the option 3, but I would argue the intent should be expressed with the balance of conciseness and simplicity of used primitives.
So I will refactor to variant 3 here, and hope you'll find the pattern 1 reasonable in the future.

how about a comment about what Boolean is?

Rather, I'll document what Boolean filters out here:

// Filter out missing and empty descriptions to avoid large gaps in the combined text

I don't think it's meaningful to just document rather simple JS features