fix(downgrade): store is_hash_attribute in __dbis__ for harperdb@4.x compat

harperdb@4.7.x reads is_hash_attribute from the __dbis__ primary-key entry to
compute LMDB DBI open flags: DBIDefinition(!is_hash_attribute, is_hash_attribute).
harper@5 only stored isPrimaryKey, so harperdb@4 opened hdb_deployment with
dup_sort=true/useVersions=false instead of the dup_sort=false/useVersions=true
it was created with, causing LMDB to throw MDB_INCOMPATIBLE. This left
databases.system.hdb_info unpopulated and checkIfInstallIsSupported fatal.

Fix: set is_hash_attribute=true alongside isPrimaryKey in databases.ts so new
tables (including those created by the 5.1.0 directive) carry the backward-compat
field. The 5.1.0 directive also now patches the __dbis__ entry on existing installs
that ran the directive before this fix. Re-enable the downgrade test.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: kriszyp

integrationTests/upgrade/4.x-upgrade.test.ts

@@ -105,19 +105,7 @@ suite(
 			ok(response.length > 10);
 		});
 
-		test(
-			'downgrade and start',
-			{
-				// The 5.1.0 upgrade directive adds the hdb_deployment table as a named DBI within
-				// schema/system.mdb (the shared LMDB env used by both harper@5 in legacy mode and
-				// harperdb@4). harperdb@4's initStores iterates __dbis__ alphabetically and fails
-				// when it encounters hdb_deployment (which precedes hdb_info alphabetically), so
-				// databases.system.hdb_info is never populated and checkIfInstallIsSupported throws.
-				// Downgrade from harper 5.1.x back to harperdb 4.x is therefore not supported after
-				// an upgrade that runs the 5.1.0 directive.
-				skip: 'downgrade from harper 5.1.x to harperdb 4.x is not supported after 5.1.0 upgrade directive runs (hdb_deployment DBI incompatible with harperdb@4)',
-			},
-			async () => {
+		test('downgrade and start', async () => {
 				// can we downgrade?
 				await killHarper(ctx); // kill 5.x harper
 				await startHarper(ctx, {

resources/databases.ts

@@ -970,6 +970,7 @@ export function table<TableResourceType>(tableDefinition: TableDefinition): Tabl
 		primaryKeyAttribute = attributes.find((attribute) => attribute.isPrimaryKey) || {};
 		primaryKey = primaryKeyAttribute.name;
 		primaryKeyAttribute.isPrimaryKey = true;
+		primaryKeyAttribute.is_hash_attribute = true; // backward-compat: harperdb@4.x reads this field to open the DBI with correct flags
 		primaryKeyAttribute.schemaDefined = schemaDefined;
 		// can't change compression after the fact (except threshold), so save only when we create the table
 		primaryKeyAttribute.compression = getDefaultCompression();

upgrade/directives/5-1-0.ts

@@ -26,6 +26,11 @@ const DEPLOYMENT_TABLE = terms.SYSTEM_TABLE_NAMES.DEPLOYMENT_TABLE_NAME;
 async function createHdbDeploymentIfMissing() {
 	if (databases.system?.[DEPLOYMENT_TABLE]) {
 		hdbLogger.info(`system.${DEPLOYMENT_TABLE} already exists; skipping create.`);
+		// Still run the patch — installs that created hdb_deployment before the is_hash_attribute
+		// fix was introduced have an __dbis__ entry without that field. harperdb@4.x uses
+		// is_hash_attribute to determine LMDB DBI open flags; without it the DBI is opened with
+		// wrong flags (DUPSORT set) and LMDB throws MDB_INCOMPATIBLE, breaking downgrade.
+		await patchHdbDeploymentIsHashAttribute();
 		return;
 	}
 
@@ -48,6 +53,31 @@ async function createHdbDeploymentIfMissing() {
 	await bridge.createTable(DEPLOYMENT_TABLE, createTable);
 }
 
+/**
+ * Patch the hdb_deployment __dbis__ primary-key entry to include is_hash_attribute: true.
+ *
+ * harperdb@4.x reads is_hash_attribute from __dbis__ to derive the LMDB DBI open flags
+ * (DBIDefinition(dup_sort, is_hash_attribute)). If the field is absent it opens the DBI
+ * with dup_sort=true / useVersions=false — the opposite of how harper@5 created it — which
+ * causes LMDB to throw MDB_INCOMPATIBLE and prevents harperdb@4 from starting after a
+ * 5.1.x downgrade.
+ *
+ * This is safe to call when the table already exists: it is a no-op if is_hash_attribute is
+ * already set, and writing it back is idempotent (lmdb upsert).
+ */
+async function patchHdbDeploymentIsHashAttribute() {
+	const systemTable = (databases as any).system?.[DEPLOYMENT_TABLE];
+	if (!systemTable?.dbisDB) return;
+
+	const dbiName = `${DEPLOYMENT_TABLE}/`;
+	const primaryAttr = systemTable.dbisDB.getSync(dbiName);
+	if (!primaryAttr || primaryAttr.is_hash_attribute) return; // already correct
+
+	primaryAttr.is_hash_attribute = true;
+	await systemTable.dbisDB.put(dbiName, primaryAttr);
+	hdbLogger.info(`Patched system.${DEPLOYMENT_TABLE} __dbis__ entry with is_hash_attribute=true for harperdb@4.x downgrade compatibility.`);
+}
+
 const directive510 = {
 	version: '5.1.0',
 	sync_functions: [] as Array<() => unknown>,