docs(admin): move locale-hardcoding gap from Open to Fixed

Follow-up to ff4fba3 - the admin/products + admin/categories
translation-tab locale-hardcoding gap flagged as deferred in the
bug-hunt audit docs is now fixed; updates docs/ADMIN.md's audit
section and moves docs/KNOWN-ISSUES.md's item from Open to Fixed.

docs/ADMIN.md

@@ -594,16 +594,25 @@ Found 2 real bugs in `admin/categories`, both fixed:
     `{ id: 'c', order: 0 }` (tying `a` and `c`). After the fix, the gateway
     receives the correct 3-way reshuffle: `c:0, a:1, b:2`.
 
-One real gap was found but **not** fixed inline (real feature work, not a
-wiring bug - see `docs/KNOWN-ISSUES.md`): both `admin-product-form.component`
-and `admin-category-form.component` hardcode their translation-tab locales to
-`['en', 'ru', 'hy']` rather than reading the tenant's actual configured
-`supportedLocales` (which live on `ProjectEditorFacade.bootstrap()`, the same
-source `static-pages-editor.component.ts` already reads correctly). Wiring
-this up means threading `supportedLocales` from `ProjectEditorFacade` through
-`AdminProductsFacade`/`AdminCategoriesFacade` (neither currently depends on
-project-editor state at all) down to two presentational form components -
-real cross-feature plumbing, not a bounded bug fix.
+A third bug, found in the same pass, was fixed in a follow-up commit:
+`admin-product-form.component` and `admin-category-form.component` both
+hardcoded their translation-tab locales to `['en', 'ru', 'hy']` instead of
+reading the tenant's actual configured `supportedLocales` (which live on
+`ProjectEditorFacade.bootstrap()`, the same source
+`static-pages-editor.component.ts` already reads correctly) - neither
+`AdminProductsFacade` nor `AdminCategoriesFacade` depended on project-editor
+state at all before this. Fixed by giving both facades a `supportedLocales`
+computed (`bootstrap()?.localization.supportedLocales ?? ['en']`) and an
+`ensureLocalesLoaded()` that calls `ProjectEditorFacade.loadBootstrap()` if
+it hasn't loaded yet (same lazy-load pattern
+`AdminDashboardFacade.ensureLoaded()` already uses for the same dependency);
+both editor pages call it in their constructor and pass
+`[locales]="facade.supportedLocales()"` down to the form components, which
+now iterate a `locales: string[]` `@Input()` instead of the literal array.
+Verified live: both `facade.supportedLocales()` and the form's bound
+`locales` changed from the hardcoded `['en','ru','hy']` to the real tenant
+order `['ru','en','hy']` (default locale first), confirmed by the rendered
+tab order in both editors.
 
 The already-documented, deliberately-scoped-down items from earlier sprints
 (related-products picker limited to the current page, not a full catalog

docs/KNOWN-ISSUES.md

@@ -76,21 +76,6 @@ don't fix inline unless asked.
    auth-system check first (does one exist yet?) before building the menu.
    - Found: 2026-07-17, project-editor bug-hunt audit.
 
-6. **Admin product/category translation tabs hardcode `['en', 'ru', 'hy']`
-   instead of reading the tenant's configured `supportedLocales`.**
-   `admin-product-form.component.html` and `admin-category-form.component.html`
-   both `@for (locale of ['en','ru','hy']; ...)` over a fixed literal array
-   rather than `ProjectEditorFacade.bootstrap().localization.supportedLocales`
-   (the same source `static-pages-editor.component.ts` already reads
-   correctly). A tenant with fewer or different supported locales gets
-   translation tabs for languages it doesn't support, and no tab at all for
-   ones it does. Not fixed inline: neither `AdminProductsFacade` nor
-   `AdminCategoriesFacade` currently depends on project-editor state, so this
-   needs real cross-feature plumbing (facade -> facade -> two presentational
-   form components), not a bounded wiring fix.
-   - Found: 2026-07-17, `admin/products` + `admin/categories` bug-hunt audit
-     (`docs/ADMIN.md`'s "Bug-hunt audit pass" section).
-
 ## Fixed
 
 1. **Full-project UX/UI + motion pass across storefront, admin dashboard,
@@ -229,10 +214,17 @@ don't fix inline unless asked.
      backend unreachable in this environment, so via
      `facade.categories.set([...])` synthetic siblings feeding the same
      facade methods/gateway calls the UI drives).
-   - One further gap found but deferred as real feature work, not a wiring
-     bug - see Open item 6 above: `admin-product-form`/`admin-category-form`
-     hardcode translation-tab locales to `['en','ru','hy']` instead of the
-     tenant's actual `supportedLocales`.
+   - A third bug from the same audit pass, fixed in a follow-up commit:
+     `admin-product-form`/`admin-category-form` hardcoded translation-tab
+     locales to `['en','ru','hy']` instead of the tenant's actual
+     `supportedLocales`. Fixed by giving `AdminProductsFacade`/
+     `AdminCategoriesFacade` a `supportedLocales` computed +
+     `ensureLocalesLoaded()` reading/lazily-loading
+     `ProjectEditorFacade.bootstrap()` (same pattern
+     `AdminDashboardFacade.ensureLoaded()` already uses), threaded down to
+     both form components via a new `locales` `@Input()`. Verified live:
+     rendered tab order changed from the hardcoded `['en','ru','hy']` to the
+     real tenant order `['ru','en','hy']` in both editors.
 
 ## Notes (not bugs, just flag before shipping)