Validate sqlite_schema before AUTOINCREMENT schema writes

[kumarUjjawal]

Description

• Hardened translate_create_table to verify sqlite_schema exists before using it.
• Replaced panic-prone unwrap() calls with:
  • bail_parse_error!("sqlite_schema table not found in schema")

Motivation and context

Issue #3764 called out a possible SQLite parity edge case around AUTOINCREMENT behavior when schema metadata is unusual/corrupted (notably relevant to future PRAGMA writable_schema support).

Description of AI Usage

[turso-bot]

Please review @sivukhin

[sivukhin]

Hi @kumarUjjawal!
Thanks for the contribution.

I think that for case you handled it is actually fine to crash - because at the moment of translation we must have properly parsed schema and if we are not - we must return NOT A DB error earlier.

Also, I think that the original issue in sqlite (https://sqlite.org/src/info/d8dc2b3a58cd5dc29) focused on the cases where sqlite_sequence table is corruption - not the case when whole schema is broken and can't be parsed.

So, I think that unwrap in the current code is ok. Instead we better to add more safe guards related to the sqlite_sequence logic particularly.

[Pavan-Nambi]

Yeah the issue isn't about panic..

Also can u edit pr description so bot won't autoclose the issue ?imo even with guards I think we should have issue open until we support writable_schema...

[codspeed-hq]

Merging this PR will degrade performance by 15.72%

❌ 1 regressed benchmark
✅ 278 untouched benchmarks
⏩ 105 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	concat_blobs	1.4 µs	1.7 µs	-15.72%

---

_{Comparing kumarUjjawal:fix/autoincrement_scheama_validation (e614db5) with main (b8ca98b)}

Footnotes

1. 105 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩