Merge bitcoin/bitcoin#32100: doc: clarify the documentation of Assume assertion

329a0dc doc: clarify the documentation of `Assume` (ismaelsadeeq)

Pull request description:

  An Expression inside `Assume` may be optimized away in production builds when the compiler proves they are side-effect-free.
  This use case is demonstrated in #31363 and is suggested to be documented in bitcoin/bitcoin#31363 (comment).

ACKs for top commit:
  l0rinc:
    ACK 329a0dc
  hodlinator:
    re-ACK 329a0dc
  jonatack:
    ACK 329a0dc
  rkrux:
    re-ACK 329a0dc

Tree-SHA512: 4bbb807a1e632694863c1a1fa2e93cc5a756b19f8d78f0642ebe7ffafb01835765fa66c76a680dc6f3c412a5abb0c4a33fb7212c26b4b2d80b6b3b7ee8284b2e

Author: fanquake

doc/developer-notes.md

@@ -460,7 +460,10 @@ other input.
   safely continue even if the assumption is violated. In debug builds it
   behaves like `Assert`/`assert` to notify developers and testers about
   nonfatal errors. In production it doesn't warn or log anything, though the
-  expression is always evaluated.
+  expression is always evaluated. However, if the compiler can prove that
+  an expression inside `Assume` is side-effect-free, it may optimize the call away,
+  skipping its evaluation in production. This enables a lower-cost way of
+  making explicit statements about the code, aiding review.
    - For example it can be assumed that a variable is only initialized once,
      but a failed assumption does not result in a fatal bug. A failed
      assumption may or may not result in a slightly degraded user experience,