A PageFileConfig built with an object initializer gets LockTimeout.Immediate: every lock fails at once under contention #322

What happens

A PageFileConfig built with an object initializer, for example new PageFileConfig { AllowMultiProcessAccess = true } (the pattern the Normalize() doc comment uses as its example), opens with LockTimeout(Read=0ms, Write=0ms, MaxWriters=0), which is LockTimeout.Immediate. Every lock then fails at once under any contention.

Normalize() fills in PageSize and GrowthBlockSize from Default, but not LockTimeout. default(LockTimeout) has the same value as LockTimeout.Immediate, so the engine cannot tell "not set" from "fail fast on purpose".

Measured on main (0450b97): new BLiteEngine(path, new PageFileConfig { AllowMultiProcessAccess = false }), then 4 tasks × 50 auto-committing InsertAsync on one collection: 150 of 200 inserts throw TimeoutException. The same workload with PageFileConfig.Default throws none.

Why it matters

• The doc comment on PageFileConfig.LockTimeout says it defaults to LockTimeout.Default. That is true only for the presets (Small, Default, Large, Server, DetectFromFile).
• Normalize() says it makes "a partially-constructed PageFileConfig ... always valid", and its example config gets fail-fast locks.
• It is the strongest form of A commit that waits for another commit's disk sync fails with TimeoutException after 500 ms: LockTimeout.Default is tuned for an unsynced WAL #303: a healthy database that rejects most concurrent writes.

Possible fixes

1. Give LockTimeout a hidden "was set" flag (set by Immediate, Default, From and the init accessors), and have Normalize() replace an unset value with LockTimeout.Default. Equality stays on the three values.
2. Or make Immediate distinguishable from default some other way, and document that default(LockTimeout) means "use the default".
3. At minimum, correct the two doc comments so they say that an initializer without LockTimeout gets Immediate.

Connected

• A commit that waits for another commit's disk sync fails with TimeoutException after 500 ms: LockTimeout.Default is tuned for an unsynced WAL #303 / PR fix(storage): raise LockTimeout.Default to 5 s so writers queued behind slow commits do not time out (#303) #321: LockTimeout.Default 500 ms → 5 s. fix(storage): raise LockTimeout.Default to 5 s so writers queued behind slow commits do not time out (#303) #321 does not change this case: a partial config still gets 0 ms.
• Epic: reliability before features — durability, AOT, query correctness and oracle coverage #288 (reliability epic).