[TheeCoderAhmed]

Fixes #2715

After assigning alasql.tables.t.data on a table with a PRIMARY KEY or UNIQUE key, the key index still describes the old rows. INSERT stores a duplicate key and DELETE throws Something wrong with primary key index on table. UPDATE already worked, because it rebuilds the index when a key is missing.

table.insert, table.delete and table.update now all call syncKeyIndexes before they use a key index. It compares table.data with the array the indexes were last built from, and rebuilds them if the array has been replaced. The rebuild moved into a small rebuildKeyIndex helper, and UPDATE's existing rebuild on a missing key now uses it too, so rows pushed onto the same array still work there.

Other things to check in review:

• DELETE ... WHERE and TRUNCATE also replace table.data, so the next statement on that table does one rebuild, which is O(n). A DELETE ... WHERE already walks every row, so I do not expect this to matter, but I did not run test-perf.
• TRUNCATE left its old keys in the index, so inserting a key again after it failed. The same check fixes this, and test2715.js has a case for it.
• Pushing rows onto the same array is not detected for INSERT and DELETE. The issue is about assigning table.data, so I left that as it is.

What I ran:

• bun test --preload ./test/bun-setup.js ./test/test2715.js: 6 of the 7 cases failed before the source change (Missing expected exception, Something wrong with primary key index on table). All 7 pass after it.
• bun test --dots --preload ./test/bun-setup.js ./test/test[0-9]*.js after sh build.sh: 2550 pass, 213 skip, 0 fail
• prettier --check on the two changed files: clean

I did not run the browser test suite, test-perf or the older Node versions in CI.