feat: indicate history filters with no matching branch/tag

[JC-Chung]

What

When a history filter (Include/Exclude on a local branch, remote branch, branch folder, or tag)
no longer has a matching branch/tag in the current repository state, its chip now shows a
distinct color instead of the usual green (Included) / red (Excluded).

Why

There was previously no way to tell whether a filter chip was still meaningfully applied.
A filter becomes unmatched when its target branch/tag is deleted/renamed outside of SourceGit
(e.g. another terminal, fetch --prune). Users may still want to keep such rules in case a
branch/tag with the same name reappears later, so unmatched filters are only flagged, never
auto-removed.

How

• Models.HistoryFilter gains a runtime-only HasNoMatch flag (not persisted).
• ViewModels.Repository recomputes HasNoMatch whenever branches or tags are (re)loaded
  (RefreshBranches/RefreshTags, including on first repository open) and whenever filters
  themselves change (RefreshHistoryFilters), so the state is always accurate without
  requiring the user to trigger a filter change first.
• Filter chip border color now factors in both Mode and HasNoMatch via a new multi-value
  converter.

Out of scope

• No automatic removal of unmatched filters.
• No extra git queries — matching is done against already-loaded in-memory branch/tag data.

[love-linger]

I do not like this design. I've pushed my implementation for this feature:

[JC-Chung]

I do not like this design. I've pushed my implementation for this feature:

No problem, thanks for handling it! As long as it's easy to tell apart, that works for me.

[love-linger]

There was a little bug. I've force pushed a new commit that fixes it.