L10n (Pt): matches all Portuguese locales, not only bare pt

[HashimAbdulaziz]

Summary

359cb0a79a3531e382fdb0c99357252936f08bf2 renamed the key from pt_BR to pt but kept
the exact-match guard, changing only the compared string. The guard was correct when the
key was region-qualified; now it means only the literal string pt matches, so every real
Portuguese locale falls through to goto error and aborts:

$ LC_ALL=pt_BR.utf8 fastfetch --key-language ""
Error: Language 'pt_br' is not supported
$ echo $?
221

All 8 Portuguese locales installed on this machine (pt_BR, pt_PT, and their
.utf8 / .iso88591 / @euro variants) abort. Only the literal value pt, which no
system sets as a locale, still works.

Before that commit, LC_ALL=pt_BR.utf8 printed Sistema operacional.

Related issue

N/A — noticed while testing key-language auto-detection across installed locales.

Changes

• case 'pt' now returns the offset unconditionally, matching every other two-letter case
  (de, es, fr, it, …), so pt, pt_BR and pt_PT all resolve to Portuguese.

zh deliberately keeps its guard — bare zh and zh_HK still error, as the comment above
the switch describes. pt has no equivalent ambiguity between two written forms, and no
comment claiming the strictness is intentional, so this reads as leftover shape from the
rename rather than a design decision. If you did intend pt to be exact-only, say so and
I'll close this.

One note: the strings are Brazilian (Sistema operacional; European Portuguese would be
Sistema operativo), so this maps pt_PT onto Brazilian wording. That follows from
naming the key pt, and is still closer than falling back to English — but it's your call.

Testing

Fedora 43, x86_64, glibc 2.42. Differential over all 890 locales from locale -a,
--key-language "", against 2de674ec9:

	count
identical	882
aborted before, works now	8
regressions	0

The 8 are exactly the pt_* locales. zh_CN / zh_TW still resolve, zh and zh_HK
still error. Explicit --key-language pt and --key-language pt_BR both work; other
explicit values are unaffected. Valgrind: 0 bytes lost, 0 errors.

Screenshots

No visual changes.

Checklist

• I have tested my changes locally.