sqlite: no more destructive version bumps

[owenlin0]

Why

We'd like SQLite state to become required and load-bearing. As a first step, let's remove the mechanism that allows us to blow away the SQLite DB on a version bump, and instead rely on graceful migrations.

The original motivation (PR) behind this mechanism was to care less about backwards compatibility while SQLite was being landed, but I'd say it's quite important now to keep the data in it.

What changed

• Make STATE_DB_FILENAME and LOGS_DB_FILENAME the full canonical filenames: state_5.sqlite and logs_2.sqlite.
• Remove STATE_DB_VERSION / LOGS_DB_VERSION and the helper that constructed filenames from versions.
• Stop StateRuntime::init from scanning for or deleting older SQLite DB filenames at startup.
• Delete the tests that encoded legacy state/logs DB deletion behavior.

Verification

• cargo test -p codex-state