100% type coverage

[jorenham]

Summary

Following #825, this fills in the last couple of missing annotations, bringing the structlog public type coverage to a beautiful 100% 🎉

Before:

$ pyrefly coverage check --public-only src/structlog
 WARN `structlog.contextvars.STRUCTLOG_KEY_PREFIX_LEN` is untyped [coverage-missing]
  --> src/structlog/contextvars.py:35:1
   |
35 | STRUCTLOG_KEY_PREFIX_LEN = len(STRUCTLOG_KEY_PREFIX)
   | ------------------------
   |
 WARN `structlog.dev.rich_traceback` is untyped [coverage-missing]
   --> src/structlog/dev.py:471:5
    |
471 | /     def rich_traceback(*args, **kw):
472 | |         raise ModuleNotFoundError(
473 | |             "RichTracebackFormatter requires Rich to be installed.",
474 | |             name="rich",
475 | |         )
    | |_________-
    |
 WARN `structlog.processors.format_exc_info` is untyped [coverage-missing]
   --> src/structlog/processors.py:427:1
    |
427 | format_exc_info = ExceptionRenderer()
    | ---------------
    |
 WARN `structlog.processors.dict_tracebacks` is untyped [coverage-missing]
   --> src/structlog/processors.py:448:1
    |
448 | dict_tracebacks = ExceptionRenderer(ExceptionDictTransformer())
    | ---------------
    |
 WARN `structlog.threadlocal.ThreadLocal` is untyped [coverage-missing]
  --> src/structlog/threadlocal.py:47:1
   |
47 | ThreadLocal = _determine_threadlocal()
   | -----------
   |
ERROR type coverage 98.89% (622 of 629 typable) is below the 100.00% threshold

After:

$ pyrefly coverage check --public-only src/structlog
 INFO type coverage 100.00% (630 of 630 typable)

Pull Request Checklist

• I acknowledge this project's AI policy.
• This pull request is not from my main branch.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.
• There's tests for all new and changed code.
• New APIs are added to our typing tests in api.py.
• Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    • The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 26.1.0, the next version is gonna be 26.2.0. If the next version is the first in the new year, it'll be 27.1.0.
• Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) are documented in the changelog.

---

Again, no AI was used; it was way too much fun to do this myself, after all :)

Oh and if you want, I could (as follow-up) add a light-weight CI job or something to ensure that coverage stays at 100%?