docs: fix heading case and terminology consistency

client-sdks/advanced/attachments.mdx

@@ -61,7 +61,7 @@ Most demo applications use Supabase Storage as the storage provider, but the pat
 |-------|-------------|
 | `QUEUED_UPLOAD` | File saved locally, waiting to upload to remote storage |
 | `QUEUED_DOWNLOAD` | Data model synced from another device, file needs to be downloaded |
-| `SYNCED` | File exists both locally and in remote storage, fully synchronized |
+| `SYNCED` | File exists both locally and in remote storage, fully synced |
 | `QUEUED_DELETE` | Marked for deletion from both local and remote storage |
 | `ARCHIVED` | No longer referenced in your data model, candidate for cleanup |
 
@@ -141,7 +141,7 @@ The queue needs to know which attachments exist in your data model. The `watchAt
 - **Missing attachments** - Upload them  
 - **Removed attachments** - Archive them
 
-The `watchAttachments` queries are reactive and execute whenever the watched tables change, keeping the attachment queue synchronized with your data model.
+The `watchAttachments` queries are reactive and execute whenever the watched tables change, keeping the attachment queue in sync with your data model.
 
 There are a few scenarios you might encounter:
 

client-sdks/advanced/local-only-usage.mdx

@@ -11,7 +11,7 @@ A caveat is that if the user never registers, this queue will keep on growing in
 
 There are two general approaches we recommend for this:
 
-### 1\. Local-only tables
+### 1\. Local-Only Tables
 
 <Tabs>
   <Tab title="Flutter">
@@ -77,7 +77,7 @@ The following example implementations are available:
 | Flutter To-Do List App (with Supabase) | [supabase-todolist-optional-sync](https://github.com/powersync-ja/powersync.dart/tree/main/demos/supabase-todolist-optional-sync)         |
 | React To-Do List App (with Supabase)   | [react-supabase-todolist-optional-sync](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist-optional-sync) |
 
-### 2\. Clearing the upload queue
+### 2\. Clearing the Upload Queue
 
 The upload queue can be cleared periodically (for example on every app start-up), avoiding the growth in database size over time. This can be done using:
 

client-sdks/advanced/sequential-id-mapping.mdx

@@ -90,7 +90,7 @@ We can achieve this by creating SQL triggers.
 ## Create SQL Triggers
 
 We need to create triggers that can look up the integer ID for the given UUID and vice versa.
-These triggers will maintain consistency between `list_id` and `list_uuid` in the `todos` table by ensuring that they remain synchronized with the `id` and `uuid` columns in the `lists` table;
+These triggers will maintain consistency between `list_id` and `list_uuid` in the `todos` table by ensuring that they remain in sync with the `id` and `uuid` columns in the `lists` table;
 even if changes are made to either field.
 
 We will create the following two triggers that cover either scenario of updating the `list_id` or `list_uuid` in the `todos` table:

client-sdks/advanced/unit-testing.mdx

@@ -65,7 +65,9 @@ test('INSERT', () async {
 });
 ```
 
-#### If you have trouble with loading the extension, confirm the following
+### Troubleshooting Extension Loading
+
+If you have trouble loading the extension, confirm the following:
 
 Ensure that your SQLite3 binary install on your system has extension loading enabled. You can confirm this by doing the following
 

sync/advanced/sharded-databases.mdx

@@ -20,27 +20,27 @@ Where feasible, using separate PowerSync Service instances would give better per
 
 Some specific scenarios:
 
-#### 1\. Different tables on different databases
+#### 1\. Different Tables on Different Databases
 
 This is common when separate "services" use separate databases, but multiple tables across those databases need to be synced to the same users.
 
 Use a single PowerSync Service instance, with a separate connection for each source database ([planned](https://roadmap.powersync.com/c/84-support-for-sharding-multiple-database-connections); this capability will be available in a future release). Use a unique [connection tag](/sync/advanced/schemas-and-connections) for each source database, allowing them to be distinguished in your [Sync Streams](/sync/streams/overview) or [Sync Rules](/sync/rules/overview).
 
-#### 2a. All data for any single customer is contained in a single shard
+#### 2a. All Data for a Single Customer Is Contained in a Single Shard
 
 This is common when sharding per customer account / organization.
 
 In this case, use a separate PowerSync Service instance for each database.
 
-#### 2b. Most customer data is in a single shard, but some data is in a shared database
+#### 2b. Most Customer Data Is in a Single Shard, but Some Data Is in a Shared Database
 
 If the amount of shared data is small, still use a separate PowerSync Service instance for each database, but also add the shared database connection to each PowerSync Service instance using a separate connection tag ([planned](https://roadmap.powersync.com/c/84-support-for-sharding-multiple-database-connections); this capability will be available in a future release).
 
-#### 2c. Data for a single customer is split across multiple shards
+#### 2c. Data for a Single Customer Is Split Across Multiple Shards
 
 This is more complicated than the other cases listed above. Please [reach out to us](/resources/contact-us) if this is your architecture. 
 
-#### 3\. Only some tables are sharded
+#### 3\. Only Some Tables Are Sharded
 
 In some cases, most tables would be on a shared server, with only a few large tables being sharded.