Stretch goal: generic numeric boundary/sign-manipulation test case (unlocks crAPI rows 5/8/9/10)

Tracked in docs/TRACEABILITY.md, crAPI rows 5/8/9/10 and "why the numbers look like this" section.

crAPI's business-logic misses (negative-quantity exploit inverting a debit into a credit, balance manipulation, undocumented-field leaks) are currently tagged "technically unreachable by any generic scanner" — but two of them are actually a generalizable pattern, not crAPI-specific:

1. Numeric boundary/sign-manipulation testing: try negative, zero, and extreme values on any numeric request field (quantity, amount, count, price), then check whether the response indicates the value inverted expected behavior (e.g. a balance/credit field increased instead of decreased). Not crAPI-specific — a real new generic test case.
2. Undocumented-field mass assignment: extend the existing BOPLA mass-assignment logic to try submitting values for any field observed in a GET/read response, not just a fixed guess-list (isAdmin/role/etc.) — catches "update internal properties" style bugs generically.

This is ambitious, not guaranteed — flagging as a stretch goal, not a quick fix. If it works, it's a genuinely new capability, not just a crAPI-specific patch, and would need unit tests + live verification against crAPI same as everything else on this project.

Start with docs/TRACEABILITY.md, the crAPI rows 5/8/9/10, and the “why the numbers look like this” section, then inspect the existing BOPLA mass-assignment logic. Define unit-test coverage and live verification against crAPI for numeric boundary/sign manipulation and observed-field mass assignment; done means the generic cases work without relying on crAPI-specific guesses.