Rewrite Python comments in Google developer documentation style (#12)

* Rewrite comments in Google developer documentation style

Rewrite the comments and docstrings across the backend core modules so they
read plainly. The previous prose was accurate but dense and figurative, which
made it slow to skim.

Applies the Google developer documentation style guide: short sentences, active
voice, present tense, American spelling, and no metaphors, idioms, or
rhetorical asides. Replaces em-dash chains with separate sentences.

backend/tests/schema_rewind.py

@@ -1,35 +1,35 @@
 """Make a database look like an older schema version, so a migration can run.
 
-`create_all` always builds the *current* schema. A test that wants to watch a
-migration happen therefore has to take the newer columns back off before it
-stamps an older version — otherwise the migration meets a table that already
-has its column and dies on a duplicate.
+`create_all` always builds the current schema. A test that wants to watch a
+migration run must remove the newer columns first and then stamp an older
+version. Otherwise the migration finds a column that already exists and
+fails on a duplicate.
 
-Rewinding the stamp alone was enough for a while, which is why two test files
-did exactly that. It stopped being enough the moment another `ADD COLUMN`
-landed after theirs: the replay then runs migrations they never meant to
-exercise, against columns `create_all` had already made. This module is that
-rewind done properly, in one place, so appending a migration means adding its
-inverse here rather than discovering three unrelated test failures.
+Rewinding the stamp alone worked for a while, so two test files did exactly
+that. It stopped working when another `ADD COLUMN` migration landed. Without
+this rewind, the replay runs migrations the tests never intended to
+exercise, against columns `create_all` already added. This module rewinds
+properly in one place. Adding a migration now means adding its inverse here,
+instead of tracking down failures in three unrelated test files.
 
-SQLite only — every test that replays migrations runs on a temp file, and
-`PRAGMA user_version` is where the stamp lives there. Migrations that change a
-column's *type* (43–45, JSON to compressed bytes) have no clean inverse and are
-not listed: they get replayed as-is, which is what the tests using them already
-relied on.
+This module supports SQLite only. Every test that replays migrations runs on
+a temp file, and SQLite stores the stamp in `PRAGMA user_version`.
+Migrations that change a column's type (43-45, JSON to compressed bytes)
+have no clean inverse, so this list omits them. Those migrations replay
+as-is, which is what the tests using them already expect.
 """
 
 from sqlalchemy import text
 from sqlalchemy.engine import Engine
 
-# (version that added it, statements that take it back off), newest first.
+# Each entry is (version that added the column, statements that remove it).
+# The list is ordered newest first.
 #
-# Phase 14's `branch_id` columns are deliberately absent: SQLite refuses to drop
-# a column a foreign key names ("unknown column in foreign key definition"), so
-# a current-schema database cannot be rewound past them at all. That is what
-# `migrations._column_already_there` is for — the replay skips DDL that has
-# already happened, so the tree migrations run their backfill against a schema
-# that already has the columns, which is exactly the situation here.
+# Phase 14's `branch_id` columns are missing on purpose. SQLite refuses to
+# drop a column that a foreign key references, so a current-schema database
+# cannot be rewound past them. `migrations._column_already_there` handles
+# this case. It skips DDL that already ran, so the tree migrations run their
+# backfill against a schema that already has the columns.
 _UNDO: list[tuple[int, tuple[str, ...]]] = [
     # Packed float32 vectors and the flag beside them.
     (39, ("ALTER TABLE memories DROP COLUMN embedded",)),