chore: constrain the fastfields-dlpack dependency to the 0.1 line

[balbasty]

Part of fastfields/fastfields-lib#18 — the "unpinned fastfields-dlpack dep in
the wrappers" item. One of four sibling PRs (fastfields-numpy, -torch,
-cupy, fastfields).

What changed

 dependencies = [
- "fastfields-dlpack",+ "fastfields-dlpack~=0.1",
"numpy",
]

fastfields-dlpack was a bare, unversioned requirement, so a resolver could
satisfy it with anything — including a future 1.x whose binding ABI and shared
enums no longer match this wrapper.

Why ~=0.1 and not an exact pin

~=0.1 expands to >=0.1, ==0.*. Every fastfields distribution is versioned
off the same 0.1 line (versioningit's default-tag = "0.1") and they are
meant to move together, so the line is the right granularity:

version	satisfies ~=0.1
0.1	✅
0.1+28.g532f58a (current dev build)	✅
0.1+cpu / 0.1+cu128 (release wheels)	✅
0.9.9	✅
1.0	❌

An exact ==0.1 would go stale the moment the tag moves and would reject the
local-version-labelled wheels the fastfields/whl index ships; a bare
requirement gives no protection at all. This is the middle ground the issue
asks for: "don't silently resolve to an incompatible future major version".
(The table was evaluated with packaging, not recalled from memory — the
local-version cases in particular are easy to get wrong.)

Verification

• Config-only; no file under fastfields/ is touched.
• python -c "import tomllib; tomllib.load(open('pyproject.toml','rb'))"
  parses, and project.dependencies resolves to
  ['fastfields-dlpack~=0.1', 'numpy'].
• pytest tests/ from a neutral cwd gives the identical result with and
  without this change (96 passed / 25 failed either way — I re-ran it with
  the change stashed to confirm). Those 25 failures are pre-existing on main
  in this sandbox, where the installed fastfields-dlpack binary is older than
  main's tests; dependency metadata is not consulted at runtime, so this PR
  neither causes nor fixes them. Flagging rather than quietly reporting green.

One thing worth watching in live CI

The reusable python-test.yml installs
fastfields-dlpack @ git+https://github.com/fastfields/fastfields-bind-py@main
beforepip install ".[test]". That source build resolves to
0.1+<distance>.g<rev> via versioningit, which satisfies ~=0.1, so the
constraint should be transparent. The one way it could bite: if versioningit
ever falls back to its default-version = "0+unknown" (a checkout with no git
metadata), that build would now be rejected where it was previously
accepted silently. I'd call that the constraint doing its job, but it is a
behaviour change worth knowing about before merge.

Workstream: claude-jitfields-to-fastfields

🤖 Generated with Claude Code

---

Generated by Claude Code