build: use uv_build backend for publishable packages and re-enable --require-hashes

[MvLieshout]

What

• Switch the five publishable packages (openstef-core, openstef-models, openstef-beam, openstef-foundation-models, openstef-meta) from the hatchling build backend to uv's native uv_build.
• Re-enable --require-hashes on those package builds in the build poe task (reverted in fix: revert require hashes. #1009).

Why

uv build --require-hashes was reverted in #1009 because it cannot be satisfied with hatchling: hatchling builds in an isolated PEP 517 environment whose build dependencies are not in uv.lock and cannot be hash-pinned, so uv has no hashes to verify.

uv_build is built into uv and performs an in-process direct build — no isolated environment and no third-party build backend to resolve/install/hash — so hashed builds pass. Verified locally: all five packages build under uv build --package <pkg> --require-hashes.

Notes

• All five packages use a src layout (src/<module>) with the module name matching the normalized project name, which is exactly uv_build's default, so their [tool.hatch] build.targets.wheel.packages blocks are dropped with no replacement config needed.
• requires = ["uv_build<0.12"] is an upper bound only (no lower bound to maintain); uv recommends an upper bound so the published sdist stays buildable when a future breaking uv_build ships.
• The root openstef meta-package stays on hatchling: it ships no module (only dependencies), and uv_build requires a module. It is built without --require-hashes — it contains only metadata, no code. openstef-deployment-examples remains excluded from the publishable set.
• uv.lock is unchanged (build backends are not locked dependencies).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud