[BUG] Reopen after non-transactional writes can overflow oracle timestamp

[feichai0017]

🐛 Bug Description

When non-transactional API writes use nonTxnMaxVersion = MaxUint64, reopening DB can initialize oracle with max version and trigger overflow in nextTxnTs.Store(committed + 1).
Subsequent txn commit path can panic on timestamp assertions.

Code path:

• db.go:28 (nonTxnMaxVersion)
• db.go:206 (recoveredVersion := db.lsm.MaxVersion())
• txn.go:80 / txn.go:91 (committed + 1)
• txn.go:193 (AssertTrue)

🛠 Reproduction Steps

1. Use non-transactional Set to write at least one key.
2. Close DB and reopen.
3. Create and commit a txn.
4. Observe panic/assert due to timestamp state corruption.

📋 Expected Behavior

Non-txn sentinel version must not be used to advance transactional oracle timestamp.
Reopen should keep valid monotonic txn timestamp state.

📸 Screenshots / Logs

Observed in repro: assert panic at txn.go:193 after reopen + txn commit.

💻 Environment

• OS: macOS 26.2 (arm64)
• Go Version: go1.24.4
• NoKV Version: current main (local HEAD on 2026-02-11)

🧐 Additional Context

High severity for mixed API usage and restart recovery.