[physics515]

FRE-14b — give the 0.1.x rows-mode tree a reader

Second part of FRE-14, stacked on the 14a branch (fre14/rows-mode-refusal, PR #95). 14a closed the
door: a 0.1.x data directory is refused at open instead of being opened as an empty store over the
top of the operator's data. This is the leg that reads it, so the refusal does not have to be the last
word. 14c (the route an operator runs) is the remaining part of the box.

What lands

• weftdb::rows_mode (new module, weftdb/src/types/rows_mode.rs), re-exported as weftdb::rows_mode:
  • discover(tree) -> LegacyTree — reports the series at <subject>/<aspect>/measurements.db: row
    count, span, how many rows share an instant; and NotCarried { path, reason } for everything the
    reading leaves in the tree — the metadata.db catalog, the databases 0.1.x kept beside the rows
    (pipeline.db, correlations.db, patterns.db, processed_*.db, unprocessed_*.db) and the
    dictionaries/ directories. It opens each series database and checks its shape first, so a tree
    that is not what 0.1.x wrote fails before a store is opened, naming the columns it did find.
  • import_into(store, tree, subject, rows_per_segment) -> ImportRecord — reads one subject into a
    store already scoped to that (database, subject); declares each aspect under the narrowest
    encoding that holds the tree's values exactly (recommend_encoding, tolerance zero); seals in
    chunks; writes the record into the store's own index under
    rows_mode_import:<database>:<subject> (record_key).
  • read_import_record(store) — reads it back after a reopen, so the idempotency is the store's, not
    a process-local memory.
• Typed refusals (RowsModeError, inside anyhow::Error, downcast_ref recovers it):
  NoCatalog, NoSeries, RowShape, ValueNotDecimal, ScopeMismatch, NoSubject, AspectNotEmpty,
  SchemaConflict, AlreadyImported. Every one names the file or the aspect it stopped on.

Decisions worth reviewing

An aspect's name comes from its directory, and the value column must be value. 0.1.x's DDL
(v0.1.0:weftdb/src/types/aspect.rs:475-480) creates measurements (id TEXT, dataset_id TEXT, timestamp INTEGER, value TEXT) and writes nothing that names the series into it. An earlier revision
of this branch accepted "whichever column is named after the aspect", on a story about a 2322 migration
renaming the column — there is no such migration in the tag, and the story was mine rather than the
source's. It was also a hazard: an aspect named id, dataset_id or timestamp would have had its
identifiers read out as its measurements, with nothing afterwards able to say so. pick_value_column
now requires the pair that DDL created and refuses the rest;
a_series_database_that_is_not_the_shape_0_1_x_wrote_is_refused pins that, and
an_aspect_named_after_an_identifier_column_is_still_read_from_value pins the other side: an aspect
actually called dataset_id is a legal series whose name comes from its directory and whose values
come from value, never from the column that shares its name.

The timestamp unit is declared, never derived. TIMESTAMP_UNIT / TIMESTAMP_TIME_UNIT say millis
because 0.1.x stamped timestamp_millis() into the INTEGER
(v0.1.0:weftdb/src/types/database/inputs.rs:142, :187) whatever the aspect's recorded resolution
claimed — that column is the sampling grid. The other tree in the same fixture, from the same release
and the same rows.csv, is second-scale, because 0.1.x's batch path kept seconds while its rows-mode
path kept millis. Same fixture, two trees, two units, factor of a thousand: an import that infers from
the size of the numbers has a way to be wrong that looks plausible on both sides. The fixture test
asserts the rows-mode import declares Millis and the migrated store declares Seconds; the constant
doc, the module doc and compat/fixtures/v0.1.0/README.md all say so. From the store's side the same
trap is closed by an_aspect_declared_at_another_timestamp_scale_refuses_the_reading: an aspect the
operator declared by hand at Seconds, holding no rows yet, refuses the reading with both schemas
printed instead of filing its rows a thousand-fold off.

Chunks never split rows that share an instant. This one is a store hazard rather than a legacy one,
and it is why rows.chunks() is not used: reconcile_segment folds two segments whose windows
intersect under merge_newer_wins, keeping only the newer row at an instant both hold
(weftdb/src/types/segment_store.rs:3666-3672). A group of same-instant rows cut across two segments
would therefore be trimmed by a compaction this reading does not control, after the import had already
looked clean. chunks_keeping_instants_together extends a chunk past rows_per_segment until the group
ends, so a segment may come out a few rows longer than asked — the cheaper side.

Reading the same tree twice refuses (AlreadyImported) rather than skipping. After a reading, a
migrated row and a row the store sealed itself are indistinguishable — 0.1.x's ids are UUID transaction
ids that are not carried, and the store has no record of which rows came from where. Refuse or
duplicate is the only honest pair of options. The ImportRecord is what makes the refusal possible at
all, and it records the counts, the encodings chosen, duplicate_timestamps, and what stayed behind.

The tree keeps its bytes. Each series database is opened bare, deliberately not through the control
plane's connect/enable_mvcc_full (which switches journal mode, i.e. writes). A read-only open is not
used because a WAL-mode database — the shipped fixture has a measurements.db-wal beside every series —
can need WAL recovery at open, which a read-only connection cannot perform. The guarantee is held by
test instead: every file found before the reading is byte-identical after it, and the fixture test
compares the copy against the release's own bytes file for file.

Test evidence

• the_v010_rows_mode_tree_reads_into_a_store_of_its_own_database (weftdb/tests/compat_v010.rs) — the
  tree the v0.1.0 binary wrote: 371 rows (237 price, 54 temp, 80 flow — the non-null subset of
  rows.csv; rows-mode has no nulls, the release's generator skipped them) carried into a store of that
  tree's own database and read back as the same exact decimals at instants a thousand times the grid's
  numbers; not_carried covers every .db the tree holds; a second reading refuses and writes nothing;
  the tree is byte-identical afterwards.
• weftdb/src/types/rows_mode.rs tests: 13 — shape refusals (missing catalog, wrong value column,
  not-a-tree), the identifier-name case above, the round trip of rows and of the record through a
  reopen, ScopeMismatch, AspectNotEmpty, SchemaConflict, AlreadyImported, ValueNotDecimal
  (including what a partway reading leaves behind), byte-identity of the tree after a reading, and
  a_chunk_never_splits_rows_that_share_an_instant.
• Fixture gate: the bytes under compat/fixtures/v0.1.0/ are unchanged by this branch — the tree is
  read, never rewritten, and git status shows only its README.md gaining the warning about the
  two timestamp scales.
• cargo +stable test -p weftdb --lib, --test compat_v010, cargo +nightly fmt --all -- --check,
  cargo +stable clippy -p weftdb --all-targets, cargo +stable doc -p weftdb --no-deps: .

Not in this branch

• 14c: the route an operator runs (CLI/server), the numbered migrations that register metadata.db's
  schema, and a tree too big to hold one aspect in RAM — the encoding decision here reads the whole
  column into memory.
• The metadata.db catalog is not read at all in this slice: its schema is what 14c registers, and
  guessing it now would be a schema this branch has no reason to pin.
• A tree whose directory name disagrees with its own catalog row is trusted to its directory — stated
  in the module doc as a known limitation.