Fix terminology: Replace 'inline' with 'in-table' storage

src/explanation/whats-new-2.md

@@ -64,7 +64,7 @@ zarr_array : <object@store> # Path-addressed for Zarr/HDF5
 ### What Changed
 
 Legacy DataJoint overloaded MySQL types with implicit conversions:
-- `longblob` could be blob serialization OR inline attachment
+- `longblob` could be blob serialization OR in-table attachment
 - `attach` was implicitly converted to longblob
 - `uuid` was used internally for external storage
 

src/how-to/use-object-storage.md

@@ -13,7 +13,7 @@ OAS supports two addressing schemes:
 | **Hash-addressed** | Object store | Content hash (MD5) | Blobs, attachments (with deduplication) |
 | **Schema-addressed** | Object store | Schema structure | NumPy arrays, Zarr, HDF5 (browsable paths) |
 
-Data can also be stored **inline** directly in the database column (no `@` modifier).
+Data can also be stored **in-table** directly in the database column (no `@` modifier).
 
 For complete details, see the [Type System specification](../reference/specs/type-system.md).
 
@@ -26,15 +26,15 @@ Use the `@` modifier for:
 - Zarr arrays and HDF5 files
 - Any data too large for efficient database storage
 
-## Inline vs Object Store
+## In-Table vs Object Store
 
 ```python
 @schema
 class Recording(dj.Manual):
     definition = """
     recording_id : uuid
     ---
-    metadata : <blob>           # Inline: stored in database column
+    metadata : <blob>           # In-table: stored in database column
     raw_data : <blob@>          # Object store: hash-addressed
     waveforms : <npy@>          # Object store: schema-addressed (lazy)
     """