docs: convert narrative US spellings to UK English

AGENTS.md

@@ -10,7 +10,7 @@ LLM-based agents can accelerate development only if they respect our house rules
 
 | Requirement  | Rationale |
 |--------------|-----------|
-| **British English** spelling (`organisation`, `licence`, *not* `organization`, `license`) except technical US spellings like `synchronized` | Keeps wording consistent with Chronicle's London HQ and existing docs. See the University of Oxford style guide for reference. |
+| **British English** spelling (`organisation`, `licence`, *not* `organisation`, `license`) except technical US spellings like `synchronized` | Keeps wording consistent with Chronicle's London HQ and existing docs. See the University of Oxford style guide for reference. |
 | **ASCII-7 only** (code-points 0-127). Avoid smart quotes, non-breaking spaces and accented characters. | ASCII-7 survives every toolchain Chronicle uses, incl. low-latency binary wire formats that expect the 8th bit to be 0. |
 | If a symbol is not available in ASCII-7, use a textual form such as `micro-second`, `>=`, `:alpha:`, `✓`. This is the preferred approach and Unicode must not be inserted. | Extended or '8-bit ASCII' variants are *not* portable and are therefore disallowed. |
 

README.adoc

@@ -289,7 +289,7 @@ It achieves this by generating efficient data accessors from Java interfaces.
 Chronicle-Values is designed to provide:
 
 * **High Performance & Low Latency:** Access and manipulate data with minimal overhead, crucial for systems where every microsecond counts. This is particularly true when using its "native" (off-heap) implementations.
-* **Minimized GC Impact:** Through the use of off-heap 'flyweight' objects, which act as lightweight views onto raw byte data. This significantly reduces garbage collection pressure by avoiding the creation of numerous heap objects.
+* **Minimised GC Impact:** Through the use of off-heap 'flyweight' objects, which act as lightweight views onto raw byte data. This significantly reduces garbage collection pressure by avoiding the creation of numerous heap objects.
 * **Type Safety:** Define your data structures using standard Java interfaces. This provides compile-time checking, clear API contracts, and reduces runtime errors.
 * **Developer Convenience:** The library automatically generates the necessary accessor boilerplate (getters, setters, etc.) based on your interface definition and intuitive annotations. This saves development time and reduces manual coding errors.
 * **"Zero-Deserialization" Access:** Read data directly from memory without the traditional cost of hydrating full heap objects, allowing for faster processing.

src/main/adoc/decision-log.adoc

@@ -10,14 +10,14 @@ The requirement tags referenced here originate from link:project-requirements.ad
 * Date: 2025-05-26
 * Context:
 ** Need for a type-safe, efficient, and developer-friendly way to represent and manipulate data with well-defined, fixed-size schemas (e.g., financial messages, event payloads).
-** Desire to minimize GC impact and integrate smoothly with other Chronicle libraries like Map and Queue.
+** Desire to minimise GC impact and integrate smoothly with other Chronicle libraries like Map and Queue.
 ** Requirements: CV-FN-001, CV-FN-003, CV-FN-007, CV-FN-008, CV-NFP-011, CV-NFP-012, CV-UX-026.
 * Decision Statement:
 ** Chronicle Values *will be adopted* as the primary mechanism for modeling and accessing structured, fixed-size data, particularly when type safety, developer convenience, and integration with Chronicle Map/Queue are priorities.
 * **Alternatives Considered:**
 ** _Direct use of Chronicle Bytes for all structured data_:
 *** *Description:* Manually managing offsets and data interpretation within Chronicle Bytes buffers for all structured data.
-*** *Pros:* Maximum control over memory layout; potentially the absolute lowest latency if hand-optimized perfectly.
+*** *Pros:* Maximum control over memory layout; potentially the absolute lowest latency if hand-optimised perfectly.
 *** *Cons:* Higher development complexity; error-prone (offset miscalculations, type misinterpretations); poor type safety at compile time; more boilerplate code.
 ** _Using third-party serialization libraries (e.g., Protocol Buffers, Avro) on top of Chronicle Bytes_:
 *** *Description:* Employing external libraries for defining structures and serializing/deserializing them into/from Bytes buffers.

src/main/adoc/project-requirements.adoc

@@ -31,15 +31,15 @@ The Nine-Box scheme covers `FN` for functional behaviour, `NF-P`, `NF-S` and `NF
 ** _Source:_ Core design goal of both Chronicle Bytes and Values.
 * *CV-NFP-010:* The system *must* support high throughput for data processing.
 ** _Source:_ Core design goal of both Chronicle Bytes and Values.
-* *CV-NFP-011:* The system *must* minimize Garbage Collection (GC) impact by extensive use of off-heap memory for data storage.
+* *CV-NFP-011:* The system *must* minimise Garbage Collection (GC) impact by extensive use of off-heap memory for data storage.
 ** _Source:_ Key feature of Chronicle Bytes and Chronicle Values flyweights.
 * *CV-NFP-012:* The system *must* provide "zero-deserialization" access for structured data where appropriate, avoiding hydration into heap objects for reads.
 ** _Source:_ Chronicle Values flyweights.
 * *CV-NFP-013:* The system *must* ensure predictable performance characteristics, particularly for data access patterns.
 ** _Source:_ Fixed-layout nature of Chronicle Values; controlled access in Bytes.
 * *CV-NFP-014:* The system *must* support atomic operations for concurrent, lock-free programming paradigms.
 ** _Source:_ Chronicle Bytes (e.g., compareAndSwapInt) and Chronicle Values (generated atomic methods).
-* *CV-NFP-015:* The system *must* allow for efficient memory alignment of data fields to optimize access, especially for atomic operations and cache performance.
+* *CV-NFP-015:* The system *must* allow for efficient memory alignment of data fields to optimise access, especially for atomic operations and cache performance.
 ** _Source:_ Chronicle Values (@Align annotation); manual management in Chronicle Bytes.
 
 == Non-Functional Requirements - Operability (NF-O)
@@ -72,7 +72,7 @@ The Nine-Box scheme covers `FN` for functional behaviour, `NF-P`, `NF-S` and `NF
 
 == Operational / DevOps Concerns (OPS)
 
-* *CV-OPS-024:* The project build system *must* be configured to support Java annotation processing if Chronicle Values is utilized.
+* *CV-OPS-024:* The project build system *must* be configured to support Java annotation processing if Chronicle Values is utilised.
 ** _Source:_ Chronicle Values build process requirement.
 * *CV-OPS-025:* Strategies for managing schema evolution and data format compatibility across application versions *must* be defined and documented.
 ** _Source:_ Implied by analysis of schema evolution for Values and Bytes.

src/main/java/net/openhft/chronicle/values/IntegerFieldModel.java

@@ -343,7 +343,7 @@ private String genGet(
 
         // "Unsigned" value. This is a special case of the next next block, but treated
         // differently, because `readByte() & 0xFF` looks more familiar than `readByte() + 128`,
-        // also the first form is optimized on assembly level by HotSpot (unsigned treatment of
+        // also the first form is optimised on assembly level by HotSpot (unsigned treatment of
         // the value, no actual `& 0xFF` op), not sure about the second form.
         long readRange = readMax - readMin;
         if (range.min() == 0 &&