perf: spanner mutation limit increase to 80000 max_total_records

[taddes]

Description

Much of this was understanding the underlying mechanics of mutations and updating the proper math to reflect the mutation limit capacity ok 80,000 in relation to max_total_records

Some details on ths: Spanner caps mutations at 80,000 per commit, and each BSO row in the batch commit costs up to 12 mutations in the worst case (4 primary-key columns + 4 non-PK columns + a delete-and-insert on each of the two secondary indexes). On top of that, the commit pays a fixed 13 mutations of overhead: 6 for the parent user_collections upsert, 1 for the batch delete, and 6 to refresh quota counts. Solving 12N + 13 <= 80,000 gives a ceiling of 6,665 records, so we pick 6,656 (= 1,664 × 4) to preserve the same propotion the legacy 1,664/20,000 cap had, leaving 115 mutations of margin for breathing room.

• Add docs/src/syncstorage/syncstorage-spanner-db.md as the canonical reference for the Spanner backend with schema, full configuration option, and per-commit mutation budget.
• Bumped dev max_total_records in config/local.example.toml from 1666 to 6656 to match the value to Spanner's 80,000-mutation-per-commit ceiling.

To Check

• make doc-prev renders the new page cleanly (mermaid diagram + internal links)
• /info/configuration returns max_total_records: 6656 against the bumped dev config
• Ensure things look good in stage when we roll out update

Issue(s)

Helm Chart update here
Closes STOR-190.

[chenba]

Suggested change

	| `bsos` | Stores Basic Storage Objects (BSOs) the synced records. Interleaved in `user_collections`. |
	| `bsos` | Stores Basic Storage Objects (BSOs), the synced records. Interleaved in `user_collections`. |

[chenba]

Suggested change

	All `bsos` and `batches` rows are physically co-located with their `user_collections` parent Spanner's interleaving puts a user's collection metadata, BSOs, and pending batches on the same split. `ON DELETE CASCADE` from `batches` to `batch_bsos` and `user_collections` `bsos`/`batches` means parent deletes wipe descendants atomically.
	All `bsos` and `batches` rows are physically co-located with their `user_collections` parent. Spanner's interleaving puts a user's collection metadata, BSOs, and pending batches on the same split. `ON DELETE CASCADE` from `batches` to `batch_bsos` and `user_collections` `bsos`/`batches` means parent deletes wipe descendants atomically.

[chenba]

no redeploy required to change it

I'm having trouble picturing how this works. How does the running process get the new value?

[taddes]

Sry, this was in the local context when working with the config.local.toml which I altered to reflect the new value. Good catch

[chenba]

When working locally, one needs to restart the service when the settings changed no?

[taddes]

Yup, and often just a fresh cargo build (or more scoped command depending on which db)