fix(ui): pinned critical as a block, and a group that names its attack type

[elluff]

What & why

Follow-up review of the grouped alerts view shipped in #87 / #89, now live on mainnet. Three things did not hold up in use, and fixing the third needed the API to say something it was not saying.

The pinned latest-critical row read as an accident. It was distinguished only by a red left border plus a red BOTTOM border nobody intended: border-severity-critical-foreground/60 sets the colour on every edge, and TableRow already draws a bottom border, so the row inherited a red underline as a side effect. The strong accent is now scoped to the left edge, the row carries a faint critical tint closed by a deliberate edge, and a section strip sits above it.

The "latest critical" label moved out of the transaction-hash cell. Sitting beside the hash it read as an attribute of that transaction, when being pinned is a property of the row's PLACEMENT. It is now a strip above the row, saying what the pin means: kept in view regardless of the sort below. A spacer row separates the block from the sorted list.

A group row's generic file icon is gone, and the contract address gained a copy button instead. The cell shows a registry label or a truncated address, so the full bech32 value could not be selected off the screen. It stops propagation, or copying would also expand the group.

The Attack Type column held the alert count, promising a type and delivering a number. It now names the class of the group's WORST alert, the same alert the severity badge on that line describes, plus "+N more" when the group holds other kinds. The count moved under the contract name, where it describes the group.

That last one needed two new aggregates, and both carry a hazard this repo has been bitten by:

argMax((risk_band, max_class), max_score) AS worst_pair,
arraySort(groupUniqArray(max_class)) AS classes,

One argMax over a TUPLE, not two argMax calls sharing an ordering: ClickHouse breaks a tie on equal max_score arbitrarily, and two aggregates can resolve it on different rows, which would put a severity badge and an attack type belonging to two different alerts on one line. That is not theoretical. In one live query, two contracts holding the same two scores resolved to different winners, ('Critical','circular') and ('High','phishing'), each pair internally coherent. arraySort because groupUniqArray has no stable order and the tooltip would otherwise reshuffle between identical refreshes. Both aliased away from the source column names, because on 26.x an aggregate aliased to a column a sibling aggregate reads returns Code 184.

The contract_anomaly reconciliation keeps pace: a verdict that takes over a group renames its attack type as well as its band, and its synthetic class is unioned into the set SQL cannot see. The union never subtracts, since proving no sibling row still carries the stored class would need per-class counts rather than a set; over-stating by one is the safe direction for a "+N other kinds" hint, and it is documented at the merge. The API re-sorts the set at the boundary because that merge appends after SQL has sorted.

Verified on a real server, not just against a fake client

The grouped aggregate now has coverage in backend/tests/live_db/, the tier that exists because mocked clients let two ClickHouse 26.x regressions ship with green tests. Run against 26.1.3.52, the production version: the aggregate executes (no Code 184 from the two aggregates reading max_class), a group counts and names its worst alert, the class list comes back sorted, and a tie returns a coherent pair.

One honest limit: that tie test still passes with the OLD two-argMax form, because on a small dataset ClickHouse happens to pick the same row for both aggregates. It documents the invariant. What deterministically catches the old form is the query-text test, and reverting the SQL proves it fails.

Checklist

• pytest tests/ green (1282), plus 9 live-DB ClickHouse tests against 26.1.3.52
• pnpm lint && pnpm build green, pnpm test 137 passed
• uv run pytest -q green (sidecar untouched)
• No unexplained numeric literals
• Docs updated (README's grouped-endpoint row documents the two new response fields)

The five new Tailwind utilities were checked against the built CSS, because a class Tailwind cannot generate fails silently rather than erroring. That is also how the hover fix was confirmed: TableRow ships hover:bg-muted/40 and tailwind-merge does not drop it for a plain bg-*, so without restating the hover tint the pinned block came apart at the moment the analyst pointed at it.