fix: restore logging lock compatibility for py3.13

[BobTheBuidler]

Summary

• add from __future__ import annotations to defer logging type annotation evaluation
• fall back to logging._lock.acquire/release when _acquireLock/_releaseLock are missing

Rationale

• Python 3.13+ removed logging._acquireLock/_releaseLock, causing import-time crashes in dank_mids.logging during unit test collection

Details

• uses getattr to detect missing private APIs and bind to the internal lock directly
• keeps behavior unchanged on 3.10–3.12 while unblocking 3.13+ imports

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f8df4ea98d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Rebuild shipped 3.13 logging extension with this fix

This change updates only dank_mids/logging.py, but in the checked repository CPython 3.13 imports dank_mids.logging from the prebuilt dank_mids/logging.cpython-313-*.so extension first, so these new fallback assignments never execute and the import-time logging._acquireLock failure remains for compiled builds. To actually deliver the compatibility fix in the environments that consume the bundled extensions, the 3.13 binary artifact needs to be regenerated and committed with the source patch.

Useful? React with 👍 / 👎.