Migrate discrete mechanisms from internal accounting utilities to dp_accounting

`dpsynth/discrete_mechanisms` currently relies on the internal `accounting.py` module, which is intended to be deprecated by `dp_accounting`

I looked into the remaining usages to understand whether the discrete mechanisms could be migrated.
There appear to be direct equivalents for the event representation:

- ZCDpEvent(rho) → dp_accounting.dp_event.ZCDpEvent(rho)
- ComposedDpEvent → dp_accounting.dp_event.ComposedDpEvent

`dp_accounting` also explicitly uses the same _Gaussian/zCDP_ relationship when handling a ` ZCDpEvent` with `xi == 0`:

`noise_multiplier = 1 / sqrt(2 * rho)`

which is mathematically equivalent to the current zcdp_gaussian_sigma() implementation:
`sqrt(0.5 / rho)`.

The remaining helpers in the internal module include conversions/calibration such as `zcdp_eps`, `zcdp_delta`, `zcdp_rho`, `zcdp_exponential_eps`, and the GDP helpers. Some may be replaceable through RdpAccountant (get_epsilon/get_delta), while others appear to be simple mechanism-calibration formulas that may need to remain local.

Before working on the migration, I wanted to check whether there are known numerical or semantic differences between the existing zCDP accounting implementation and `dp_accounting`, or another reason the discrete mechanisms have intentionally remained on the internal accounting utilities.

If migration is the intended direction, I'm interested in working on it and can first add equivalence tests for the relevant conversions.

Start by tracing the remaining usages from dpsynth/discrete_mechanisms into the internal accounting.py module, then compare the relevant event and conversion APIs in dp_accounting, including RdpAccountant. Run or add equivalence tests for zCDP and GDP conversions where applicable; done requires a confirmed migration path or documented reasons for helpers that must remain local.

Written by the indexing model from the issue text.