APPROVE.

Clean implementation. Persistence flows through the existing useLayoutSettings localStorage scaffold; ThSort keeps the upstream @vincjo/datatables ergonomics (createSort(field).init(direction)) while exposing onSort for the parent to record the column identity. Default of { column: 'name', direction: 'asc' } matches the issue.

Non-blocking nits:

• pipelinesTableSort stores column: string rather than a union of the actual sortable field names. If a future rename of e.g. lastStatusSince ships without a migration, persisted state silently sorts nothing (no match on any column, so all five ThSorts mount with direction: undefined). A union type + a .filter(...) on read would fail loudly. Small; only matters once.
• The browser test mounts the full Table.svelte, which is great for regression coverage, but ties row-order assertions to the data-testid="box-row-…" convention in a sibling row component. Worth a one-line comment in the spec calling out that contract so a future testid rename doesn't make this test pass for the wrong reason.
• ThSort now has two static-over-lifetime props (direction, onSort) flowing in via $props(). Svelte 5 won't complain, but documenting "must be stable for the component lifetime" matches the inline comment style you already use.

Test coverage is thoughtful (rotation of date order vs name order makes the "did it actually re-sort?" assertion meaningful, and persistence is checked through the real localStorage key). Good PR.

Re-APPROVE on the force-pushed revision (b25062b → 897a6af). The rewrite is materially better than what I approved the first time round: instead of building a parallel sort state on the parent, ThSort now accepts optional direction/onSort props and the parent wires each sortable column through a tiny sortColumn(name) helper that reads/writes a single pipelinesTableSort entry through the existing useLayoutSettings + useLocalStorage scaffold. The default { column: 'name', direction: 'asc' } is right where it belongs.

The new Table.svelte.spec.ts is the highlight: name order and lastStatusSince order are deliberately rotated against each other so every assertion can only pass if the click actually re-sorted the rows, the persistence test reads back through the layout/pipelines/table/sort localStorage key, and the "restores on mount" test covers the warm path. beforeEach resets both the cached useLayoutSettings singleton and the backing store, which is the right cleanup discipline.

One non-blocking nit (still): pipelinesTableSort.value.column: string is structurally typed, so a future rename of e.g. lastStatusSince won't fail loudly — the stored value just silently won't match any header and the default-named column will appear active. Tightening this to column: NamesInUnion<…> | ((p: PipelineThumb) => unknown)['name'] (or a hand-rolled union of the five sortable field names) buys you a real compile error on rename, and the only cost is updating the useLocalStorage initializer's narrowing.

(Re mihaibudiu's "who cares about vincjo" — fair, but the comment is genuinely useful: it tells the next maintainer why ThSort.svelte exists at all instead of being imported from @vincjo/datatables. I'd keep it.)