prediction-ledger.js is missing both the schema-version convention and the tenant_id column every sibling store has

[JSONbored]

Context

packages/loopover-miner/lib/schema-version.js (#4832) documents a shared convention: every local SQLite store's bootstrap schema is version 1, and a store calls applySchemaMigrations(db, migrations) right after its CREATE TABLE IF NOT EXISTS so any post-baseline migration runs and the file's PRAGMA user_version is stamped. claim-ledger.js, event-ledger.js, run-state.js, portfolio-queue.js, plan-store.js, and governor-ledger.js all call applySchemaMigrations in their init function.

packages/loopover-miner/lib/prediction-ledger.js's initPredictionLedger never imports or calls applySchemaMigrations at all — it is the one store among the package's canonical seven (the list status.js's storeIntegrityChecks and migrate-cli.js's STORES both track) with no schema-version stamp whatsoever. migrate-cli.js's own doc comment claims "every store already applies its own pending migrations... as a side effect of being opened", which is currently false for this file.

Separately, #4939 ("Add tenant-scoping columns to all local ledger schemas") added an additive, nullable tenant_id TEXT column — a prerequisite for any future hosted, multi-tenant use of the ledger logic — to claim-ledger.js, run-state.js, event-ledger.js, and portfolio-queue.js via an addTenantIdColumn migration guarded by a PRAGMA table_info column-presence check, even though it was closed as if every ledger schema had received it. prediction-ledger.js's predictions table has no tenant_id column.

Requirements

• packages/loopover-miner/lib/prediction-ledger.js MUST import applySchemaMigrations from ./schema-version.js and call it immediately after the CREATE TABLE IF NOT EXISTS predictions statement inside initPredictionLedger, matching the call-site position used in governor-ledger.js/claim-ledger.js.
• The predictions table MUST gain a nullable tenant_id TEXT column, added via a migration function named addTenantIdColumn passed into the applySchemaMigrations call (i.e. applySchemaMigrations(db, [addTenantIdColumn])), not via an unconditional ALTER TABLE outside the migration framework.
• addTenantIdColumn MUST guard the ALTER TABLE predictions ADD COLUMN tenant_id TEXT with a PRAGMA table_info(predictions) column-presence check before altering, mirroring event-ledger.js's and run-state.js's own addTenantIdColumn implementations exactly (idempotent against a file that was already migrated).
• No consumer reads or writes tenant_id yet — self-host behavior MUST be byte-identical (every existing row and every new row inserted through appendPrediction has tenant_id = NULL), matching Add tenant-scoping columns to all local ledger schemas #4939's own stated behavior for the other four stores.
• Opening a fresh predictions table MUST result in PRAGMA user_version = 2 (BASELINE_SCHEMA_VERSION 1 plus the one addTenantIdColumn migration), verifiable via schema-version.js's exported readSchemaVersion.
• Opening a pre-existing prediction-ledger file created by the current code (no tenant_id column, user_version unset/0) MUST upgrade it in place to user_version = 2 with the column added and every existing row preserved.

Deliverables

• packages/loopover-miner/lib/prediction-ledger.js calling applySchemaMigrations(db, [addTenantIdColumn]), with addTenantIdColumn defined in that file.
• A test in test/unit/miner-prediction-ledger.test.ts asserting readSchemaVersion reports 2 on a freshly-opened store.
• A test in test/unit/miner-prediction-ledger.test.ts that creates a pre-migration on-disk file (the old bare CREATE TABLE IF NOT EXISTS predictions shape, no tenant_id, user_version 0), opens it via initPredictionLedger, and asserts the column now exists, existing rows survive, and tenant_id reads back as null for both old and newly-appended rows.

Test Coverage Requirements

packages/loopover-miner/lib/prediction-ledger.js is under packages/**, covered by this repo's 99%+ Codecov patch gate — every line of the new addTenantIdColumn function and the applySchemaMigrations call site must be exercised by the tests above, including the column-presence guard's both branches (column absent → added; column already present → left alone).

Expected Outcome

prediction-ledger.js matches every sibling local store's schema-version convention (#4832) and carries the same tenant_id hosted-readiness column (#4939) the other four ledgers already have, closing the drift between what #4939 claimed was done and what the code actually had.

Links & Resources

• packages/loopover-miner/lib/schema-version.js (Add schema versioning to the local SQLite stores #4832)
• packages/loopover-miner/lib/governor-ledger.js (reference: applySchemaMigrations(db, []) call-site position)
• packages/loopover-miner/lib/event-ledger.js / run-state.js (reference: existing addTenantIdColumn implementations)
• Add tenant-scoping columns to all local ledger schemas #4939 ("Add tenant-scoping columns to all local ledger schemas")

[linear-code]

JSO-4480