CREATE TIMESERIES TYPE adopts any sealed file already sitting at its name, so a type created one statement ago can answer rows that belong to a type dropped before it: the rename path refuses exactly this state and the create path does not #10925

Summary

#10866 and #10867 both closed, and both guard the DROP, which is the producer of a stray sealed file.
Nothing guards the CREATE, which is the consumer. So the bad state both issues were about is still
reachable, by any route that puts a file at the name rather than only by the two that were fixed.

Both fixes guard the
DROP, which is the producer of a stray sealed file. Nothing guards the CREATE, which is the consumer.

The rename path already refuses exactly this state and says why
(LocalTimeSeriesType.checkEngineFilesCanMove: "a sealed file left under that name by another type
would be adopted by this type's engine at the next open, or overwritten"). CREATE TIMESERIES TYPE
makes no such check, so any sealed file that reaches <name>_shard_<i>.ts.sealed by any means at all -
a restore from a file-level backup, a cp of a database directory, a delete that failed with the
WARNING the new code logs, the .ts.sealed.incoming residual above renamed by an operator - is adopted
silently. Reproduced at HEAD e353330c5c, verbatim:

sealed file backed up      = 507 bytes
sealed file after drop     = false
sealed file planted back   = true
existsType(Ticker) at open = false
CREATE succeeded, count(*) = 100
   row: {"ts":"2023-11-14 22:13:20","name":"S0","f1":0.0}
   row: {"ts":"2023-11-14 22:13:21","name":"S1","f1":1.0}
after reopen, count(*)     = 100

That is a type created one statement ago answering 100 rows that belong to a type dropped before it,
surviving a reopen. Dedup: alltitles.txt has no title about CREATE adopting a sealed file; #10749,
#10796 and #10867 are the neighbours and all three are about the producer side.

What would make it unbreakable: give CREATE TIMESERIES TYPE the check the rename already has - refuse
when TimeSeriesSealedStore.sealedFileNameFor(name, i) exists for any i < shardCount before the
type is registered - so the adoption is impossible whatever left the file there, rather than being
closed one producer at a time. Writing the rule once and having both the create and the rename call it
is the version that survives the next producer.

Scope / confidence

Reproduced at HEAD e353330c5c with a standalone probe against engine/target/classes, output
above. The producer routes listed (a file-level restore, a directory copy, a failed delete, an
operator renaming the .ts.sealed.incoming residual) are reasoning about how a file gets there; the
adoption itself is measured and does not depend on which of them put it there.

Dedup

The alltitles.txt checked. #10749, #10796 and #10867 are the neighbours and all three are about the
producer side. No title covers CREATE adopting a sealed file.