sql: re-seed lookup rows on upgrade

[aberoham]

A database created by 2.x has the nameserver export types and record types of its day; nothing in sql/upgrade added the ones v3 introduced, so an upgraded install can't create a coredns or native nameserver (lib/nameserver/test/runtime.js fails with unknown nameserver type: native on such a database). Found by running a 2.41 production dump through the upgrade path; with this file applied that database passes the runtime tests. INSERT IGNORE keeps an operator's own row under a clashing id; the header says how to check.

[msimerson]

Suggested change

	# Lookup rows added since NicTool 2.x. New installs get these from
	# Lookup rows added in NicTool 3.0. New installs get these from

[msimerson]

# Safe to re-run: INSERT IGNORE keeps
# existing rows. That also means a row you added yourself under one of
# these ids keeps its name and the v3 type it shadows stays unavailable;
# check with
#   SELECT id, name FROM nt_nameserver_export_type WHERE id >= 9;
# and renumber yours first if it clashes.

That sounds like really dangerous advice:

 NicTool/server/sql ➜ grep nt_nameserver_id *                            on  master [$!] via 🐪 v5.40.4 
04_nt_nameserver.sql:    nt_nameserver_id    SMALLINT UNSIGNED AUTO_INCREMENT NOT NULL,
04_nt_nameserver.sql:    PRIMARY KEY (`nt_nameserver_id`),
04_nt_nameserver.sql:    KEY `nt_nameserver_idx1` (`name`),
04_nt_nameserver.sql:    KEY `nt_nameserver_idx2` (`deleted`),
04_nt_nameserver.sql:    nt_nameserver_id    SMALLINT UNSIGNED NOT NULL,
04_nt_nameserver.sql:    KEY `nt_nameserver_log_idx1` (`nt_nameserver_id`),
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 1);
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 2);
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 3);
04_nt_nameserver.sql:    nt_nameserver_id                SMALLINT UNSIGNED NOT NULL,
04_nt_nameserver.sql:    KEY `nt_nameserver_export_log_idx1` (`nt_nameserver_id`)
08_nt_zone.sql:    nt_nameserver_id     smallint(5) unsigned NOT NULL,
08_nt_zone.sql:    UNIQUE KEY `zone_ns_id` (`nt_zone_id`,`nt_nameserver_id`)

[aberoham]

sorry I was having my clanker reason about its wanker move here, add tests to avoid similar facepalm

[aberoham]

The ubuntu-latest, 24 failure isn't from this PR. It only touches sql/, and
the same commit passed test (ubuntu-latest, 22), test-mac, test-win and
test-docker. GET /zone_record paginates has been intermittent since at
least 2026-08-24, which is when the DIAGZR instrumentation went in.

That instrumentation did catch something this run. The three records the test
creates come back with ids from the POST, then aren't in the table:

DIAGZR createdIds= [60002,60003,60211,60212,60213]
DIAGZR all-records-for-zid= [5096, 60002, 60003]

So it isn't the pagination or the search filter — rows that reported
themselves created are absent. I'm digging into that separately. This job
likely just needs a re-run to go green.