Keep extracted locale resources alive while loading translations

[kokotatan]

A default activate() call fails when humanize is imported from a ZIP on Python 3.12+: _get_default_locale_path() returns an extracted path after leaving as_file(), which has already removed the directory. gettext.translation() then raises FileNotFoundError even though the archive contains a valid catalog.

Changes proposed in this pull request:

• Keep the locale resource context open until gettext.translation() has loaded the catalog into memory. Extract only the locale directory, and preserve explicit paths, English/None handling, and translation caching.
• Add an isolated subprocess regression that imports humanize from a ZIP containing a small synthetic GNU catalog, then exercises public activate(), apnumber(), deactivate(), and reactivation. The test failed against the original implementation and passes with this change.

Validation on Windows:

• Python 3.13 full suite with all 36 locale catalogs compiled: 855 passed, 2 skipped.
• tox -e py310,py312 via tox-uv: Python 3.10 had 854 passed, 3 skipped; Python 3.12 had 855 passed, 2 skipped.
• prek run --all-files: passed using a fresh task-specific hook cache.
• Mypy and strict MkDocs build: passed.

The two skipped catalog-update tests require GNU translation tools unavailable in this environment. Directory resources in importlib.resources.as_file() require Python 3.12, so the new ZIP test skips on older Python; existing ZIP-directory support limitations on Python 3.10/3.11 remain outside this fix.

AI assistance was used for investigation, implementation, and review. The original failure and the checks above were executed locally, and the final two-file diff received two independent reviews.