What happened?

A board filter on a label stores label ids, and the set of ids is snapshotted at the
moment the filter is toggled. Because each task carries its own label row with its own id,
any task labelled afterwards is not in that list and is not matched — while the filter chip
still renders as active. Nothing in the UI indicates the filter has gone partially blind.

In apps/web/src/lib/task-filters/label-groups.ts, toggleLabelGroup collects the ids of
every label sharing a (name, color) at click time:

const groupIds = labels.filter((label) => sameGroup(label, group)).map((label) => label.id);

and task-matches-filters.ts then matches by id:

() => filters.labels?.some((id) => labelIds.includes(id)) ?? false

The filter is persisted to localStorage under kaneo:board-filters:<projectId>, so the
stale id list survives reloads and keeps decaying until someone re-toggles the filter.

This is most visible with an exclude filter: new tasks carrying the excluded label keep
appearing on a board that is supposed to hide them.

Expected: a label filter should follow the label, not a snapshot of the rows that existed
when it was set.

A second, related surprise: sameGroup compares colour exactly and case sensitively, so
#bb87fc and #BB87FC form two separate groups under the same name. An installation that
acquired both spellings through an import shows the same label twice in the filter menu, and
selecting one of them matches only part of the tasks.

How can we reproduce it?

1. Label two or three tasks on a board with the same label.
2. Set a board filter on that label — exclude is the clearest.
3. Add the same label to another task.

The new task is not excluded. Re-toggling the filter picks it up. Reloading the page does
not, since the id list is restored from localStorage.

For the colour variant: give two tasks the same label name with colours differing only in
case, and the filter menu lists the label twice.

Environment

Kaneo v2.46.2, official ghcr.io/usekaneo/kaneo image pinned by digest, external
PostgreSQL 18. Chrome.

Note

This is likely a symptom of the identity model described in #1731 ("N tasks labelled bug
produce N rows"), and the canonical-label redesign proposed there would remove it entirely.
Filing separately because it is a user-visible correctness problem with a smaller
independent fix available in the meantime — matching by (name, color) at match time, or
re-expanding the stored group against the current label list instead of trusting the
snapshot.