Fix custom dictionary-key conversion - #1238

Summary. convert() skipped dec_hook for custom dict-key types because convert_dict_to_dict sends exact-str keys straight to convert_str, bypassing the MS_TYPE_CUSTOM dispatch at the top of convert(). The PR adds that dispatch inside convert_str's ANY|STR branch.

Verified. CI has not run the test matrix on this PR, so I built the PR merged onto current main (dac6320, clean merge) on Linux, CPython 3.12, gcc:

• pytest tests/unit: 6505 passed, 146 skipped, 0 failed.
• Behaviour now matches json.decode for the same type: dict[C, int] with a dec_hook gives {C(a): 1} from json.decode, convert (strict) and convert(strict=False); dict[C | None, int] hooks once; dict[Annotated[C, Meta(...)], int] hooks.
• With no hook, convert({"a": 1}, dict[C, int]) now raises ValidationError: Expected `C`, got `str` - at `key` in `$` , identical to json.decode. Before, it silently returned the str key.
• Refcounts: 1000 calls on the same key string leave sys.getrefcount unchanged (4 -> 4), so the Py_INCREF plus ms_decode_custom steal is balanced, the same pattern as convert() (src/msgspec/_core.c:22490 on the PR head).
• A str-subclass custom key and generic custom keys behave as the new tests expect.

Findings.

1. Behaviour change worth stating in the description / release notes (src/msgspec/_core.c:21219).
   Code that relied on convert(d, dict[Custom, V]) passing str keys through (no hook, or a hook that was never called) will now raise ValidationError at key. I think that is the right behaviour (it matches json.decode, and #775 is exactly this inconsistency), but it can break existing callers.
2. Nit: the new branch is reachable from one caller only (_core.c:21219 vs :22490, :22497, :21880).
   convert() already dispatches MS_TYPE_CUSTOM before it calls convert_str for ordinary strings (:22490 before :22497), so the only way to reach the new branch with a custom type is the exact-str key shortcut in convert_dict_to_dict (:21880). Handling the custom case at that call site (or routing custom key types through convert()) would leave convert_str untouched. Not a correctness issue, just a smaller blast radius.

Not covered / unverified. No sanitizer or debug-build refcount run, no Windows/macOS, only CPython 3.12 on Linux. I did not run just check or the type-stub checks (the PR reports them passing).

Verdict. Comment. The fix is correct and the tests are thorough; finding 1 is a heads-up, finding 2 a preference.