[REF] pos_payment_method_cashdro_rounding: hook the amount, not the url builder

`_cashdro_payment_url()` is shared by the payment and the reversal paths, so
patching it applied the rounding to the reversals too: giving back a paid
order sent the drawer the *order* remaining, rounded, instead of the amount
of the line, and reversing an order already covered by other payments sent 0.

It also collided with the modules that fix that same method, leaving the
outcome to the asset load order.

Both go away by hooking `_cashdro_amount()`, the extension point
`pos_payment_method_cashdro_flow_fix` provides, which is only reached on a
payment. `shouldRound`/`getDefaultAmountDueToPayIn` came with the 18.0 tax
totals rework, so fall back instead of breaking the payment with a TypeError
the operator would read as one more connection error.

Adds the README_DEV.md the repo conventions ask for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

pos_payment_method_cashdro_rounding/README_DEV.md

@@ -0,0 +1,52 @@
+# pos_payment_method_cashdro_rounding
+
+Sends the CashDro the amount the customer is really expected to pay — the due
+amount with the PoS **cash rounding** applied — instead of the plain due amount
+the OCA module asks for.
+
+## Why
+
+A CashDro can only give change with the coins it holds. When the PoS is
+configured with a cash rounding (`pos.config.cash_rounding`, typically to 0.05
+so that 1 and 2 cent coins are not needed), asking the drawer for the unrounded
+due leaves it trying to return change it does not have.
+
+Core already computes that amount: `PosOrder.getDefaultAmountDueToPayIn()` is
+what a payment line defaults to when it is created. We simply reuse it, so the
+drawer is asked for exactly what the payment screen shows.
+
+`shouldRound()` decides whether the rounding applies at all — it takes
+`only_round_cash_method` into account, and the CashDro method is a cash one, so
+in practice it is always true when a cash rounding is configured.
+
+## How
+
+One single patch on `PaymentCashdro.prototype._cashdro_amount()`, the hook
+`pos_payment_method_cashdro_flow_fix` extracted for this. Everything else of the
+OCA payment flow (request, acknowledge, polling, error handling) is untouched.
+
+Two things this deliberately does **not** do:
+
+- It does not touch the **reversals**. There the amount to send is the one of
+  the line being given back, not the remaining of the order, and it is already
+  the rounded figure that was collected. Rounding it a second time against the
+  order total would ask the drawer to collect the total all over again.
+- It does not touch `_cashdro_payment_url()`, which is what it patched until
+  `18.0.1.1.0`. That method is shared by the payment and the reversal paths,
+  which is exactly how the reversal bug above got in, and it collides with the
+  fix modules that also patch it — the outcome then depending on the asset load
+  order.
+
+## Dependencies
+
+Needs `pos_payment_method_cashdro_flow_fix` for the `_cashdro_amount()` hook,
+and through it `pos_payment_method_cashdro_fix`: without them the OCA module
+does not work on 18.0 at all, so there is nothing to round.
+
+## Testing
+
+There are no automated tests — the flow needs a CashDro answering on the
+network. To check it by hand, configure a cash rounding of 0.05 on the PoS, take
+an order to a total that is not a multiple of 0.05 (e.g. 17.43) and confirm the
+drawer asks for 17.45. See the `USAGE` of
+`pos_payment_method_cashdro_flow_fix` for how to read a failure.