Raise ValueError/NotImplementedError instead of a generic RuntimeError based on DP error code

[kalra-mohit]

Every result/build/merge call in algorithm_builder.hpp catches a non-OK absl::Status from the C++ DP library and turns it into std::runtime_error, which pybind11 maps to a plain Python RuntimeError. That's the same exception type whether you passed in a bad epsilon, asked for a result you'd already consumed, or hit a genuine internal failure in the library. From Python there's no way to except your way out of the cases that are actually your fault versus the ones that aren't, short of parsing the message string.

What I did

I traced through the vendored differential-privacy source at the pinned submodule commit to see what status codes these specific call sites (build, result, partial_result x3, merge) can actually produce. The two I could pin down cleanly:

• kInvalidArgument - by far the most common. Covers things like bad bounds/overflow in the builder, and (somewhat non-obviously) calling result()/partial_result() a second time on the same algorithm instance, since Algorithm::PartialResult() in algorithm.h explicitly returns InvalidArgumentError once result_returned_ is already true.
• kUnimplemented - returned by the base NoiseConfidenceInterval() for algorithms that don't override it.
• kInternal - e.g. Count::Merge() on an empty Summary.

flowchart LR
    A[absl::Status from DP library] --> B{status.code}
    B -- kInvalidArgument --> C[py::value_error → ValueError]
    B -- kUnimplemented --> D[PyErr_SetString NotImplementedError]
    B -- everything else --> E[std::runtime_error → RuntimeError]

Loading

I added a small ThrowFromStatus() helper in a new status_errors.hpp and swapped it in at all six throw sites in algorithm_builder.hpp. kInvalidArgument maps to ValueError using pybind11's built-in py::value_error (already the pattern used for build errors in qunatile_tree.cpp, so this isn't introducing a new convention). kUnimplemented maps to NotImplementedError via PyErr_SetString, since pybind11 doesn't ship a wrapper for that one. Everything else - kInternal, kFailedPrecondition, anything I didn't verify - still raises RuntimeError, same as before. I didn't want to guess at mappings for codes I hadn't actually traced back to a real code path.

One existing test, test_bounded_mean.py::test_result_crash, asserted RuntimeError for the "call result() twice" case - that's actually the InvalidArgument path, so I updated it to expect ValueError and left a comment explaining why. I also added tests/algorithms/test_error_types.py with a couple of focused regression tests: one confirms the double-result case now raises ValueError (and explicitly isn't just accidentally a RuntimeError subclass), and another confirms merging an empty Summary still raises RuntimeError, so the change doesn't accidentally widen beyond what I verified.

Testing

This one's a C++ binding change, and I wasn't able to build the extension locally to run these against the real bindings - the CI workflow itself budgets 20 minutes just for the Google DP library build step, which is more than makes sense for a local sanity-check loop in this environment. What I did do:

• Read the exact status-returning code paths in the pinned differential-privacy submodule commit for every scenario the new tests exercise, rather than guessing.
• Ran black --check and clang-format --style=file (matching .clang-format, which is what this repo's CI uses) against every file I touched - all clean, no diffs.
• py_compile on the Python test files.

I'm relying on CI here to actually build and run the test suite - opening this as a draft until that comes back green, at which point I'll flip it to ready for review.

Fixes #413