fix: preserve table ordering from database in category responses

[Artuomka]

No description provided.

[Copilot]

Pull request overview

Updates the table-categories “v2” response construction so that tables within each category are returned in the same order as stored in the database (instead of the order from the global tablesRO list).

Changes:

• Build each category’s tables list by iterating category.tables and matching each name to its corresponding tablesRO entry.
• Filter out category table names that don’t exist (or are hidden) by dropping unmatched lookups.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This changes behavior when category.tables contains duplicates: the previous filter(...includes...) could only include each tablesRO entry once, but the new map(...find...) will repeat duplicates, returning the same table multiple times in the response. Consider de-duplicating category.tables (while preserving order) and/or enforcing uniqueness in table-category validation so API responses stay consistent.

Suggested change

	const tablesInCategory = category.tables
	const uniqueTableNames = Array.from(new Set(category.tables));
	const tablesInCategory = uniqueTableNames

[Copilot]

category.tables.map(...tablesRO.find(...)) performs a linear search in tablesRO for every table name (O(categoryTables * tablesRO)). For connections with many tables/categories this can add noticeable overhead; consider building a lookup map (e.g., name -> tableRO) once and then doing O(1) lookups while preserving the category.tables order.

[Copilot]

This logic is intended to preserve the DB-stored ordering of category.tables, but there’s no test asserting the returned table order within a category. Please add/update coverage (likely in the existing /table-categories/v2/:connectionId e2e test) to verify that when a category is saved with an explicit tables order, the response returns tables in that same order.