Include all coverage variants for a family in a query

[kane50613]

Fixes #322

Generated with Claude and reviewed by me

Add matching::match_fonts to collect every font sharing the best match's attributes, and have the query include the whole set. The caller already walks candidates per cluster against each font's charmap, so it now lands on the slice that covers the cluster.

[DJMcNab]

I'm happy enough for this to land as-is; it does address a real case fairly surgically.

However, I do have a couple of follow-up questions:

1. Is this definitely the right behaviour; we gate the 'later' fonts on being 'exactly as good' as the best match?
2. Presumably, a better long-term fix would be to actually implement unicode range support. Would we still need this in that case?

@kane50613, let me know when you're happy and I'll merge it.

[kane50613]

@DJMcNab Thanks for reviewing and I've guided Claude to research on how Blink does this

1. Blink does the same: FontFaceCache::GetOrCreate groups faces by attributes and font selection picks a single best bucket.
   Worse-attribute faces never fill coverage gaps, those fall through to the next family. Mixing weights/styles within one run would be worse than falling back.

2. Yes, we'd still need this. Blink builds unicode-range on the same grouping: equal-attribute faces form one CSSSegmentedFontFace, with ranges filtering within the bucket.
   It would also fix a downside of this PR: load_bucket eagerly loads every variant's blob, since without range metadata the only way to check coverage is the charmap. With ranges, subsets outside the needed range are never loaded.