feat: report the OpenSSL runtime in specify version

[Yi-111-a]

Description

specify version reported CLI version, Python, Platform, Architecture and OS Version, but nothing about the OpenSSL runtime the interpreter actually loaded.

That is the first thing HTTPS triage needs, and on Windows it is genuinely not inferable from outside the process: several unrelated toolchains ship their own libssl-3-x64.dll (Git for Windows alone has two distinct builds — mingw64\bin\libssl-3-x64.dll and usr\bin\msys-ssl-3.dll), and only the one actually loaded matters.

This came out of #4433, where the report is an OpenSSL-level abort (OPENSSL_Uplink(...): no OPENSSL_Applink) and the working hypothesis is a PATH-preceded OpenSSL DLL. Today, answering "which OpenSSL is in use?" requires the reporter to run a separate python -c snippet. After this change, specify version answers it:

┌────────────────────────── Specify CLI Information ──────────────────────────┐
│                                                                             │
│     CLI Version    1.0.7.dev0                                               │
│                                                                             │
│          Python    3.14.6                                                   │
│        Platform    Windows                                                  │
│    Architecture    AMD64                                                    │
│      OS Version    10.0.26200                                               │
│         OpenSSL    OpenSSL 3.5.7 9 Jun 2026                                 │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

The row is skipped when ssl.OPENSSL_VERSION is unavailable, so the table degrades rather than erroring.

Related to #4433 — this does not fix the abort, it only makes the runtime visible to whoever triages it.

Evidence

New test fails on main, passes with the change:

# baseline (unmodified main)
$ .venv/Scripts/python -m pytest tests/test_cli_version.py -q
tests\test_cli_version.py ......F                                        [100%]
FAILED tests/test_cli_version.py::TestVersionCommand::test_version_reports_openssl_runtime
1 failed, 6 passed in 1.44s

# with this change
$ .venv/Scripts/python -m pytest tests/test_cli_version.py -q
tests\test_cli_version.py .......                                        [100%]
7 passed in 0.44s

Lint matches what CI runs:

$ uvx ruff@0.15.0 check src tests
All checks passed!

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest
• Tested with a sample project (if applicable) — not applicable, specify version does not read a project

On the second box: tests/test_cli_version.py passes, and the specify version CLI surface was exercised directly. I could not complete the full suite on this machine — tests/conftest.py probes for a working bash and invokes wsl.exe, which is blocked by my host's security policy, and long runs get cut short. CI will cover the full matrix; I'd rather flag the gap than tick a box I didn't verify.

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (describe below)

AI assistance was used to draft the change and its test, and to run the local verification shown above. I reviewed the diff and the reported outputs.

Note: why the loaded DLL path is not in this PR

The obvious companion field is the resolved path of the loaded libssl-3-x64.dll. I left it out on purpose.

It would require process-module enumeration, and it only means something once we know a PATH-preceded DLL can be loaded at all — which is exactly what is still unresolved in #4433. On my Windows host, libssl-3-x64.dll resolves to the interpreter's own DLLs\ directory regardless of what is on PATH (CPython calls SetDefaultDllDirectories at startup, bpo-36085, so PATH is no longer part of extension-module resolution). Adding the path now would encode an unverified assumption into the UI.

If it turns out to be useful once #4433 is understood, I'm happy to follow up with it as a separate focused change.