fix(build): include missing setuptools subpackages

[CyanoTex]

Summary

The [tool.setuptools].packages list got out of sync with the source tree again — same failure mode as #97. Four subpackages exist on disk but are missing from the explicit list, so they get silently dropped from the built wheel:

• repowise.core.analysis.dead_code
• repowise.core.ingestion.extractors.bindings
• repowise.core.ingestion.extractors.heritage
• repowise.core.ingestion.resolvers.dotnet

The dotnet drop is the proximate cause of #109: csharp.py:34 does from .dotnet import get_or_build_index at import time, so any pipx/pip install of 0.4.0 fails on first repowise init before the CLI can start. The other three were never reported because nothing imports them at startup, but they're still being dropped from the wheel.

Fixes #109.

What changed

Added the four missing subpackages to [tool.setuptools].packages in pyproject.toml. No source changes.

Verification

Built locally with uv build --wheel and confirmed all four subpackages now ship in the wheel:

$ python -c "import zipfile; z=zipfile.ZipFile('dist/repowise-0.4.0-py3-none-any.whl'); print('\n'.join(sorted(n for n in z.namelist() if n.endswith('__init__.py'))))" | grep -E "(dead_code|bindings|heritage|dotnet)"
repowise/core/analysis/dead_code/__init__.py
repowise/core/ingestion/extractors/bindings/__init__.py
repowise/core/ingestion/extractors/heritage/__init__.py
repowise/core/ingestion/resolvers/dotnet/__init__.py

The original failing import chain from #109 (repowise.cli.main → cost_estimator → core.ingestion → graph → resolvers → csharp → dotnet) now resolves cleanly from a wheel install.

Re Python 3.14

The reporter hit this on 3.14, but the bug is not 3.14-specific — any Python >=3.11 install of 0.4.0 from the published wheel will hit the same ModuleNotFoundError. 3.14 classifier coverage is a separate concern and not addressed here.

Suggested follow-up (out of scope)

This is the second time in two weeks the explicit packages list has drifted from the tree (see #97). Worth considering a switch to [tool.setuptools.packages.find] with the existing package-dir mapping so newly-added subpackages get picked up automatically. Happy to file that as a separate PR if there's interest — keeping this one strictly to the fix for #109.

[CyanoTex]

Second time I've had to come in. First was because of Luau support, but now it's a bug.

[Seanathon]

Nice! And agreed, this logic will definitely benefit from auto-discovering subpackages.

[CyanoTex]

Nice! And agreed, this logic will definitely benefit from auto-discovering subpackages.

If I have to keep a Claude around every time something comes up with repowise, I will if things are breaking this regularly. 😆

[RaghavChamadiya]

@
Thanks for catching this and for the clean writeup, the verification snippet showing the four init files in the wheel made this very easy to confirm.

Verified all four subpackage dirs exist on disk and the import chain you traced from cli.main down to resolvers/dotnet matches what we are seeing on 0.4.0 from pipx. Merging now and cutting 0.4.1 right after so pipx users are unblocked today.

You are right that this is the second drift in two weeks. Going to pick up the find: switch as a separate PR after 0.4.1 is out, want to keep the patch release strictly to this fix.
@