Review fixes:

- remove information removal of non-canonical blocks
- update description for schema changes

Author: dkijania

docs/mesa-upgrade/appendix.mdx

@@ -13,30 +13,57 @@ keywords:
 
 ## Upgrading archive nodes from Berkeley to Mesa
 
-Below we presents details what was changed in the archive node database schema between Berkeley and Mesa version.
+Below we present details of what changed in the archive node database schema between Berkeley and Mesa versions.
 
-**Zkapp_state_nullable additional Columns **
-   - The `zkapp_state_nullable` table has been modified to include a new columns `element8` to `element31` which are nullable and can store additional state information for zkApps.
+### Extended zkApp State Fields
+
+**zkapp_states_nullable table**
+   - Added columns `element8` through `element31` (nullable integer fields)
+   - Each new column references `zkapp_field(id)`
+   - These fields allow zkApps to store additional state information beyond the original 8 elements
 
 ```sql
-, element8          int     REFERENCES zkapp_field(id)
+ALTER TABLE zkapp_states_nullable ADD COLUMN IF NOT EXISTS element8 INT REFERENCES zkapp_field(id);
 ...
-, element31         int    REFERENCES zkapp_field(id)
-);
+ALTER TABLE zkapp_states_nullable ADD COLUMN IF NOT EXISTS element31 INT REFERENCES zkapp_field(id);
+```
 
+**zkapp_states table**
+   - Added columns `element8` through `element31` (non-nullable integer fields)
+   - Each new column references `zkapp_field(id)` with a default value pointing to the zero field
+   - Unlike the nullable version, these fields are required and default to the zero field ID
+
+```sql
+ALTER TABLE zkapp_states ADD COLUMN IF NOT EXISTS element8 INT DEFAULT <zero_field_id> NOT NULL REFERENCES zkapp_field(id);
+...
+ALTER TABLE zkapp_states ADD COLUMN IF NOT EXISTS element31 INT DEFAULT <zero_field_id> NOT NULL REFERENCES zkapp_field(id);
 ```
 
-**Version table**
+### Migration History Tracking
 
-We also introduced a new table `version` to keep track of the database schema version.
-Purpose of this table is to help with future database migrations. Table tracks which migration scripts were applied and when.
-Ultimately it helps to determine the current version of the database schema. And helps to avoid applying the same migration script multiple times.
+The upgrade introduces a new `migration_history` table to track database schema migrations. This helps manage future upgrades and prevents applying the same migration multiple times.
 
-This table is created if it does not exist already. Rollback and upgrade scripts will insert a new row with the version number and timestamp when the script was applied.
+**migration_status enum type**
+```sql
+CREATE TYPE migration_status AS ENUM ('starting', 'applied', 'failed');
+```
 
+**migration_history table**
 ```sql
-CREATE TABLE IF NOT EXISTS version (
-    version_num INT PRIMARY KEY,
-    applied_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
+CREATE TABLE IF NOT EXISTS migration_history (
+    commit_start_at   TIMESTAMPTZ NOT NULL DEFAULT NOW() PRIMARY KEY,
+    protocol_version  TEXT NOT NULL,
+    migration_version TEXT NOT NULL,
+    description       TEXT NOT NULL,
+    status            migration_status NOT NULL
 );
-```
+```
+
+The table tracks:
+- **commit_start_at**: Timestamp when the migration started
+- **protocol_version**: Target protocol version (e.g., '4.0.0' for Mesa)
+- **migration_version**: Version of the migration script itself (e.g., '0.0.5')
+- **description**: Human-readable description of the migration
+- **status**: Current state of the migration (starting, applied, or failed)
+
+The migration script uses protocol version '3.0.0' for Berkeley and '4.0.0' for Mesa, with built-in safety checks to prevent reapplying migrations or running them on incorrect database versions.

docs/mesa-upgrade/upgrade-steps.mdx

@@ -100,8 +100,6 @@ There will be both Docker images and archive node releases available to choose f
     - Operators shall import the SQL dump file provided by o1Labs to a freshly created database.
     - Operators should direct their Mesa archive process to the newly created database.
 
-**Please note:** both the _trustless_ and _trustful_ migration processes will discard all Mainnet blocks that are not canonical. If you wish to preserve the entire block history, i.e. including non-canonical blocks, you should maintain the Mainnet archive node database for posterior querying needs.
-
 ### Exchanges
 1. Exchanges shall disable MINA deposits and withdrawals during the entirety of the upgrade downtime, since the _stop-transaction-slot_ until the Mainnet Mesa network is operational.
 2. After the Mesa releases are published, exchanges should upgrade their nodes and prepare for the new network to start block production.