Remove CLI pkg_resources dependency

[siddicky]

Summary

• replace CLI metadata and plugin discovery calls with importlib.metadata
• use the importlib-metadata backport below Python 3.8
• support both legacy group mappings and modern selectable entry points
• add regression coverage for isolated CLI startup, version output, and legacy plugin discovery

This is a smaller alternative to #248 that removes the pkg_resources fallback entirely, following the backport suggestion in that PR.

Fixes #252.
Related: #243, #245, #246, #248.

Verification

• uv run --isolated --python 3.14 --with . python -m unittest tests.test_cli: 3 tests passed
• basedpyright tests/test_cli.py: 0 errors, 0 warnings
• uv build: sdist and wheel built successfully
• clean wheel install with uv/Python 3.14: shodan --help and shodan version both exit 0
• production source contains no pkg_resources references

The existing live-API suite still has unrelated failures caused by stale Exploits/host fixtures and changed account/filter behavior; all new CLI tests pass.

[jauderho]

Some downstream data in support of this change — we hit this while containerising the CLI, and I think it's worth noting that the failure is no longer conditional on an old environment.

Reproduction: shodan 1.31.0 on Python 3.14, installed with uv into a clean venv on ubuntu:26.04:

Traceback (most recent call last):
  File "/opt/venv/bin/shodan", line 4, in <module>
    from shodan.__main__ import main
  File "/opt/venv/lib/python3.14/site-packages/shodan/__main__.py", line 33, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

shodan --help and every other subcommand exit non-zero — the import is at module scope, so nothing is reachable.

Why this is becoming the default rather than an edge case. Two independent changes stack:

1. setuptools removed pkg_resources in 81.0.0. Its own deprecation notice says "slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81."
2. pkg_resources was previously available by accident — the distro python3-pip package pulled setuptools in system-wide, so a system install of shodan happened to find it. Installing into a virtualenv (which uv, and increasingly PEP 668-era tooling generally, does by default) removes that accident. Worth noting ubuntu:26.04's python3-pip no longer provides pkg_resources either, so even the non-venv path is now broken there.

So the set of environments where the CLI works is shrinking from both directions at once.

Workaround and why it isn't durable. Pinning setuptools<81 does restore it — verified working on 80.10.2, broken on 83.0.0. But it means carrying a pinned, no-longer-maintained setuptools purely to satisfy one import, and in our case Dependabot repeatedly widened the constraint back out and silently re-broke the image until we scoped an explicit ignore for it.

That's why the importlib.metadata approach in this PR is the right fix rather than a pkg_resources fallback: there's no version of setuptools that can be safely pinned to indefinitely.