sqlite3.Connection.iterdump() produces an unrestorable dump for a populated virtual table

Bug description

sqlite3.Connection.iterdump() emits INSERT statements for a virtual table's
own rows in addition to its schema. Those rows live in the shadow tables (which
are dumped separately), and on restore they run before the virtual table module
is instantiated, so restoring the dump fails:

import sqlite3
src = sqlite3.connect(":memory:")
src.execute("CREATE VIRTUAL TABLE t USING fts4(x)")
src.execute("INSERT INTO t(x) VALUES ('hello world')")
script = "".join(src.iterdump())
dst = sqlite3.connect(":memory:")
dst.executescript(script)
# sqlite3.OperationalError: no such table: t

The SQLite shell's .dump does not emit content rows for virtual tables.

CPython versions tested on

3.14, 3.15, 3.16

Operating systems tested on

macOS

Linked PRs

• gh-153730

まず sqlite3.Connection.iterdump() を使って例を再現し、その出力を SQLite の .dump の動作と比較します。完了条件は、データが投入された仮想テーブルのダンプを新しい接続で実行しても、報告されている no such table エラーが発生しないことです。作業はすでにこの issue に関連付けられているため、開始前にリンクされている PR gh-153730 を確認してください。