docs(order-book): reserve "CLOB" for teaching/ecosystem context only

Audit pass to align with the project rule: use "order book" / "order-book"
by default; reserve "CLOB" for the introductory acronym definition, the
H1 heading (searchability for finance-literate readers), the Cargo
package description first-mention, and ecosystem-mapping references
to other CLOBs (Phoenix, Openbook v2).

Replaced "CLOB" with "order book" / "order-book" in:

  - README §1 "What does this program do?" passing reference ("runs an
    onchain order book for a single pair of token mints")
  - README §6.2 "This is the standard order-book rule"
  - README §6.2 "...of an order book."
  - README §6.3 "A production order book would add:"
  - README §8 "For a production order book it's wrong"
  - README §8 "In an order book an attacker chooses the inputs"
  - test_order_book.rs doc-comment header, scenario comments, and
    create_market_user / matching engine comments
  - matching.rs "standard order-book rule"
  - slab/nodes.rs ("this order book is fixed-price only")
  - slab/ordertree.rs ("Callers in this order book embed a...")
  - TERMINOLOGY.md title and the "balance" example phrasing

Kept as "CLOB":

  - README H1 "Order Book \u2014 Central Limit Order Book (CLOB)" (searchability)
  - README §1 first-mention teaching pattern
  - README §1 "production Solana CLOBs to read alongside it" (ecosystem)
  - README §1 "Real Solana CLOBs (Openbook v2, Phoenix)" (ecosystem)
  - place_order.rs comment "Real CLOBs (Openbook v2, Phoenix) use a similar" (ecosystem)
  - Cargo.toml package description (one mention for crates.io searchability)

Tests: 24/24 still pass (comment-only changes).

Author: Edward (Mike's bot)

defi/order-book/anchor/README.md

@@ -3,7 +3,7 @@
 This is an **order book** — specifically, a **central limit order
 book (CLOB)**, the standard piece of market infrastructure used by
 NYSE, NASDAQ, LSE, CME, and every major crypto venue. An Anchor
-program that runs an onchain CLOB for a single pair of token mints:
+program that runs an onchain order book for a single pair of token mints:
 users post buy or sell offers at the prices they want, the program
 matches crossing offers in price-time priority, and settles the
 resulting token movements.
@@ -1106,8 +1106,8 @@ From [`errors.rs`](programs/order-book/src/errors.rs):
 - **Matching applies at the maker's price, not the taker's.** The
   fill price is always the resting order's price. Takers that cross
   deeper into the book get price improvement, refunded to
-  `unsettled_quote` (for taker bids). This is the standard CLOB
-  rule.
+  `unsettled_quote` (for taker bids). This is the standard
+  order-book rule.
 
 - **Fees come out of the gross.** The maker receives `gross - fee`,
   not `gross`; the fee lives on for a while in `quote_vault` before
@@ -1144,11 +1144,11 @@ From [`errors.rs`](programs/order-book/src/errors.rs):
   check happens at the end. A bid that clears enough asks to free
   up 3 slots can then rest its own 1-slot remainder even on a
   previously-full book — matching the "liquidity-positive" spirit
-  of a CLOB.
+  of an order book.
 
 ### 6.3 Things this example does *not* do
 
-A production CLOB would add:
+A production order book would add:
 
 - **Zero-copy OrderBook.** 100 entries per side deserialised every
   call limits both throughput and maximum book size.
@@ -1328,12 +1328,12 @@ Ordered by difficulty.
 
 The current example stores each side of the book as a `Vec<OrderEntry>`
 sorted by price. That's fine for a teaching example with a few dozen
-resting orders. For a production CLOB it's wrong, and the reason is
+resting orders. For a production order book it's wrong, and the reason is
 worth understanding before the "Zero-copy slabs" bullet below.
 
 **Tree balancing must be guaranteed, not assumed.** A plain binary
 search tree only keeps a roughly-balanced shape when its inputs arrive
-in random order. In a CLOB an attacker chooses the inputs — the prices
+in random order. In an order book an attacker chooses the inputs — the prices
 of their orders — so nothing they choose can be allowed to determine
 the tree's shape. A *balanced-by-construction* tree (red-black,
 critbit / binary radix trie, AVL, …) enforces a bounded shape via

defi/order-book/anchor/TERMINOLOGY.md

@@ -1,4 +1,4 @@
-# Terminology Rules — CLOB
+# Terminology Rules — Order Book
 
 Project-wide rules for the README and code comments in this crate. Applies
 throughout, not just one section. Audit for these before opening / merging
@@ -15,7 +15,7 @@ A wrong or ambiguous statement is worse than no statement.
 
 ### "balance" — most important
 
-`balance` is ambiguous in a CLOB context: it can mean token balance,
+`balance` is ambiguous in an order-book context: it can mean token balance,
 account balance, **or** the tree-balancing property (the critbit
 slab is balanced-by-construction). Pick one of:
 

defi/order-book/anchor/programs/order-book/src/state/matching.rs

@@ -29,7 +29,7 @@ pub struct Fill {
     pub fill_quantity: u64,
 
     /// Price at which the fill clears. Always the resting (maker) order's
-    /// price — standard CLOB rule: maker's posted price wins; the taker
+    /// price — standard order-book rule: maker's posted price wins; the taker
     /// gets price improvement vs their limit on bids, and a higher payout
     /// vs their limit on asks. Also the high 64 bits of the tree key when
     /// we look the leaf up again at apply time.

defi/order-book/anchor/programs/order-book/src/state/slab/nodes.rs

@@ -2,7 +2,7 @@
 // MIT-licensed. See LICENSE-OPENBOOK in this directory.
 //
 // Trimmed from the upstream nodes.rs:
-//   - dropped oracle-pegged price helpers (this CLOB is fixed-price only)
+//   - dropped oracle-pegged price helpers (this order book is fixed-price only)
 //   - dropped time-in-force / expiry tracking (no IOC/post-only here)
 //   - dropped client_order_id and owner_slot (the on-chain `Order` PDA
 //     already owns that bookkeeping)

defi/order-book/anchor/programs/order-book/src/state/slab/ordertree.rs

@@ -245,7 +245,7 @@ impl OrderTreeNodes {
     /// Insert `new_leaf` into the tree rooted at `root`.
     ///
     /// Returns the handle of the new leaf and, when a duplicate key collided,
-    /// the leaf that got overwritten. (Callers in this CLOB embed a
+    /// the leaf that got overwritten. (Callers in this order book embed a
     /// monotonically increasing seq_num in every key, so collisions cannot
     /// actually happen — the case is kept just to match the upstream API.)
     pub fn insert_leaf(

defi/order-book/anchor/programs/order-book/tests/test_order_book.rs

@@ -1,4 +1,4 @@
-//! LiteSVM tests for the CLOB program.
+//! LiteSVM tests for the order-book program.
 //!
 //! Covers the full lifecycle that the program supports: initialise a market,
 //! create user accounts, place bids/asks (locking the appropriate vault),
@@ -152,7 +152,7 @@ fn full_setup() -> Scenario {
     let quote_mint = create_token_mint(&mut svm, &authority, MINT_DECIMALS, None).unwrap();
 
     // Create and fund every trader's ATAs up-front so individual tests do
-    // not need to worry about mint/ATA side effects, only about CLOB state.
+    // not need to worry about mint/ATA side effects, only about order-book state.
     let buyer_base_ata =
         create_associated_token_account(&mut svm, &buyer.pubkey(), &base_mint, &payer).unwrap();
     let buyer_quote_ata =
@@ -219,7 +219,7 @@ fn full_setup() -> Scenario {
 
 /// Build the `system_program::CreateAccount` instruction the client must run
 /// to allocate the ~180 KB OrderBook account before calling
-/// `initialize_market`. The new account is owned by the CLOB program and
+/// `initialize_market`. The new account is owned by the order-book program and
 /// zero-initialized; the program then runs `load_init` against it in the
 /// next instruction.
 ///
@@ -331,7 +331,7 @@ fn build_place_order_ix(
 }
 
 /// Build a `place_order` instruction with maker (order, market_user) PDA
-/// pairs appended as remaining accounts. The CLOB expects them in the same
+/// pairs appended as remaining accounts. The order-book program expects them in the same
 /// order the resting book will be walked — best-priced first (lowest ask
 /// for a taker bid, highest bid for a taker ask), and within a price level
 /// earliest-first. Every maker pair must be writable: the program mutates