0.1.3 wheels ship the Bazel build tree (bazel-project/, top_level.txt lists bazel-bin, kokoro, ...) #118

The published 0.1.3 wheels include the repository's Bazel build tree as a top-level bazel-project/ package, alongside cel_expr_python/.

Observed in cel_expr_python-0.1.3-cp314-cp314-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl from PyPI:

• 1,291 of the wheel's 1,314 entries are under bazel-project/. They include cel_basic_test.py, codelab/, conformance/, custom_ext/ and release/setup.py, plus external/rules_python+/... (rules_python's own sources and tests).
• cel_expr_python-0.1.3.dist-info/top_level.txt lists bazel-bin, bazel-out, bazel-project, bazel-testlogs, build, build_area, build_deps, dist, kokoro and tmp, as well as cel_expr_python.
• Installing the wheel adds about 16 MB to site-packages that cel_expr_python never imports.

This breaks a real consumer. The wheel contains bazel-project/external/rules_python+/python/runfiles/__init__.py. aspect_rules_py's venv builder treats any installed path ending in runfiles/__init__.py as rules_python's runfiles package, and tries to write its shim at <site-packages>/runfiles/__init__.py. When no top-level runfiles package exists, every py_test that depends on cel-expr-python fails before the test starts:

Error:   × Unable to run command:
  ├─▶ Unable to write to runfiles __init__.py file
  ╰─▶ No such file or directory (os error 2)

We currently work around this with a post-install patch that deletes that file.

Expected: the wheel contains only cel_expr_python/ (and its .dist-info), and top_level.txt lists only cel_expr_python. The release packaging seems to collect every directory in the build workspace, possibly through packages=find_packages() or a broad package_data glob in release/setup.py run from the Bazel workspace root.