Fix CI: Restore user's PiecewiseLinearFunction implementation after upstream merge

[Copilot]

Merging pyvrp:main replaced the fork's custom PiecewiseLinearFunction implementation with the upstream's incompatible version, breaking mypy, C++ compilation, and tests.

Root Cause

The two PLF implementations are semantically incompatible:

	This fork	Upstream PyVRP
Constructor	Default (zero fn) + explicit	Explicit only
Shape	n+1 breakpoints, n segments	n breakpoints, n segments
is_zero()	✅	❌

The upstream's _pyvrp.pyi stub required both breakpoints and segments as mandatory args, so PiecewiseLinearFunction() in Model.py failed mypy. Without a default constructor, C++ compilation would also fail.

Changes

• pyvrp/cpp/PiecewiseLinearFunction.h — Restored fork's implementation: default zero constructor, isZero(), and n+1 breakpoints / n segments semantics with domain-checked evaluation:

  PiecewiseLinearFunction([0, 5_000, INT_MAX], [(0, 1), (5_000, 11)])
  //                       ^--- 3 breakpoints, 2 segments

• pyvrp/cpp/bindings.cpp — Restored PLF binding with default args ([min, max] / [(0,0)]) and is_zero() method; use pyvrp::Duration/pyvrp::Cost types instead of int64_t
• pyvrp/_pyvrp.pyi — Restored stub: breakpoints/segments optional, is_zero() -> bool, types as int instead of np.int64
• tests/test_PiecewiseLinearFunction.py — Replaced upstream tests (wrong semantics) with fork's tests covering domain checks, is_zero(), and correct n+1/n shape invariant

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.