Say what the availability answer is actually based on

The caveat "quantities committed on open orders are not deducted" stopped being
true when placing an order line started decrementing stock. Deducting them now
would count them twice — the API gained the filters that would have made the
deduction possible, and the right conclusion was that it is no longer the thing
to build.

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

workflows/README.md

@@ -89,6 +89,22 @@ and through the A2A facade, `escalate: true` becomes a task in state **failed**
 rather than a completed one — the honest shape for "a human has to look at
 this".
 
+### Deducting open orders would double-count
+
+The answer used to end with *"quantities committed on open orders are not
+deducted"*. That caveat is now **wrong**, and acting on it would be worse than
+leaving it: placing an order line decrements stock in the same transaction, so
+an open order has already taken what it needs. Subtracting it again counts it
+twice.
+
+The API gained the filters that would have made the deduction possible —
+`list-order-details` takes `productcode` and `ordernumber__status` — and the
+right conclusion was that the deduction is no longer the thing to build.
+
+What remains true, and is said once: the order lines that came with the seed
+data predate the stock movement and never decremented anything. They are
+history, not commitments.
+
 ### It now knows what the reactive half saw
 
 `check-availability` reads the watchlist before answering, so a crossing that