feat: depend on the groundingdino conda package instead of vendoring it

[phreed]

Part of #1 — this is the downstream half. The upstream half is
IDEA-Research/GroundingDINO#458, #459, #460 and #461.

Removes the vendored copy of GroundingDINO and depends on the conda package instead.

Why

Every change this repository had made under groundingdino/ is now a pull request against
upstream, and the conda-forge feedstock builds the result. Keeping a fork in a subdirectory
after that buys nothing and actively hides which changes are ours.

The four files, and where they went:

File	Upstream PR
models/GroundingDINO/bertwarper.py	IDEA-Research/GroundingDINO#458
models/GroundingDINO/csrc/MsDeformAttn/ms_deform_attn_cuda.cu	IDEA-Research/GroundingDINO#459
version.py	IDEA-Research/GroundingDINO#460
config/GroundingDINO_SwinB_cfg.py	IDEA-Research/GroundingDINO#461

What survives, and why it has to

groundingdino/config/ stays. Twenty call sites across eighteen files load those two model
configs by path, not by import:

CONFIG_PATH = "groundingdino/config/GroundingDINO_SwinB_cfg.py"

groundingdino/__init__.py is deleted, and that deletion is the load-bearing part of this
change rather than tidying.

A groundingdino/ directory in the working directory is found before site-packages. With an
__init__.py it is a regular package and wins immediately, silently shadowing the conda package
that is supposed to replace it. Without one it is only a namespace portion: Python records it,
keeps scanning sys.path, finds the installed regular package, and uses that.

docker/Dockerfile.ros2 now asserts this at image build time rather than leaving it to be
discovered at run time:

RUN python3 -c "import groundingdino, sys; p = groundingdino.__file__ or ''; \
    sys.exit(0) if 'site-packages' in p or 'dist-packages' in p else \
    sys.exit(f'groundingdino resolved to {p!r}, not the installed package')"

Also removed

• setup.py — existed to build the vendored CUDA extension.
• recipe.yaml — built the detector; the feedstock owns that now.
• pixi.toml — merged into pyproject.toml, so one file describes this project to both pip
  and pixi. Two files stating the same dependency set is how they drift apart.
• pixi.lock — regenerated against the new environment.
• Dockerfile — GroundingDINO's own, inherited by the fork. It COPYs docker_test.py, which
  exists upstream and not here, so it has been unbuildable since the fork, and nothing
  references it.
• environment.yaml — superseded by [tool.pixi], and pointed at a requirements.txt that has
  never existed in this repository (the file is r.txt).

docker/Dockerfile.ros2 also asked pip for that same nonexistent requirements.txt; fixed while
in the area. It now clones GroundingDINO and compiles the extension from there, pinned to the
branch carrying the four fixes until they merge upstream.

Dependency changes worth review

[project].dependencies is deliberately empty and [tool.pixi.dependencies] is the single
authoritative list. Stating the same names in both makes pixi resolve them a second time against
PyPI, where groundingdino-py is still 0.4.0 and carries none of these fixes:

Because only groundingdino-py<=0.4.0 is available and you require
groundingdino-py>=0.4.1, we can conclude that your requirements are unsatisfiable.

It would be wrong even if it resolved — torch from PyPI beside pytorch from conda is two
builds of one library in one environment.

The pytorch and nvidia channels are gone, and with them the channel-priority = "disabled"
they needed to coexist. groundingdino-py-cuda is built against conda-forge's CUDA pytorch, so
drawing pytorch from the pytorch channel would mix two builds of it. One channel, one pytorch.

The CUDA build toolchain drops out of the environment entirely — cuda-nvcc, cuda-toolkit,
gxx_linux-64, ninja, and the libcublas / libcusolver / libcusparse / libcurand -dev
packages were all there only to compile the vendored extension.

Swap groundingdino-py-cuda for groundingdino-py-cpu and the environment resolves on a machine
with no GPU at all — correctly, but slowly, and it must stay in float32 because grid_sample has
no half-precision CPU kernel.

Verified

resolves to : .../st/.pixi/envs/default/lib/python3.10/site-packages/groundingdino/__init__.py
extension   : ['..._C.cpython-310-x86_64-linux-gnu.so']
_C forward  : True
local config: groundingdino | training params: True

Not mergeable yet

pyproject.toml points at a local channel, because groundingdino-py 0.4.1 does not exist
publicly until conda-forge/groundingdino-py-feedstock#3 lands and publishes.

That feedstock PR no longer waits on upstream review: it builds upstream's own tree and carries
the three fixes as patches, which is conda-forge's mechanism for exactly this. So the remaining
chain is short — feedstock merges and publishes, this drops the local channel and comes out of
draft. The upstream PRs can land on their own schedule; each patch is deleted as its PR does.

docker/Dockerfile.ros2 still clones phreed:integration/split-fixes. That container builds the
extension with pip rather than installing the conda package, so it needs a git ref rather than a
channel. It is a fetchable branch and only a build-time input, but it is worth revisiting once the
upstream PRs merge — at which point it can clone IDEA-Research/main directly.