[FE] Guard the Competency Management route by taxonomy type (redirect non-Competency taxonomies)

• Building the Competency Management page and its competency tree (#680).
• The "Apply Competencies" entry point (#663) and the "Import Competency Framework" button (#706).
• The taxonomy-type field itself and its backend plumbing: the frontend field is #616, the backend that produces the type is #618/#630. This ticket only reads the type, it doesn't build it.
• Behavior for a taxonomy id that does not exist or the user cannot access. That is an error case, not a redirect case, and it reuses whatever the taxonomy-detail page already does for the same failure.
• Any change to the shared Loading component or to useTaxonomyDetails.

Files to Modify

Implementation Notes

Resolve the taxonomy for :taxonomyId via the existing taxonomy-detail query (useTaxonomyDetails or equivalent) and read its type using #616's predicate.

Reuse the gate ladder TaxonomyDetailPage.jsx already uses, in the same order, and insert the type check as a fourth rung:

1. !isFetched → return <Loading />, importing the shared Loading from src/generic/Loading.tsx exactly as TaxonomyDetailPage.jsx:13 does. Do not write a new spinner, do not inline a Paragon Spinner, and do not reach for LoadingSpinner (the named export, which is the bare inline spinner for small in-page regions). The default export gives the full-page centered treatment this route needs, and reusing it keeps the competency route visually identical to the detail page during load, which matters because the guard's whole job is to be invisible when it passes.
2. isError || !taxonomy → the same error treatment the detail page gives that case, so a missing or forbidden id behaves consistently across both routes. Keep this rung ahead of the type check: an errored query has no type, and treating "no type" as "not a Competency" would silently redirect a broken fetch instead of reporting it.
3. Not a Competency type → <Navigate to={/taxonomy/${taxonomyId}} replace />. replace is required so the back button does not bounce into a redirect loop.
4. Otherwise render #680's page.

Example Resolution Prompt

In frontend-app-authoring, add a taxonomy-type guard to the Competency Management route /taxonomy/:taxonomyId/competencies (the page built by #680). At the page entry (or a route wrapper — match #680's structure), resolve the taxonomy via the existing taxonomy-detail query (useTaxonomyDetails or equivalent) and check its type using the predicate #616 introduces (isCompetencyTaxonomy-style; confirm its actual name). Mirror the gate ladder in src/taxonomy/taxonomy-detail/TaxonomyDetailPage.jsx:35-41 in the same order: while !isFetched, return the shared <Loading /> from src/generic/Loading.tsx (the default export, the full-page centered spinner, imported the same way TaxonomyDetailPage.jsx:13 imports it, not a new spinner and not the LoadingSpinner named export); then on isError || !taxonomy, show the same error treatment the detail page shows, keeping this ahead of the type check so a failed fetch is reported rather than silently redirected; then, if it is a Competency taxonomy, render #680's page; otherwise redirect with <Navigate to={/taxonomy/${taxonomyId}} replace /> (the taxonomy detail/editing page; confirm this is the intended destination). No error page for the type mismatch itself; that redirect is silent and immediate. Add RTL tests: a Competency taxonomy renders the page, a non-Competency taxonomy redirects to /taxonomy/:taxonomyId without showing the page, an unfetched query renders Loading and neither the page nor a redirect, an errored id shows the error state rather than redirecting, and the redirect uses replace so there's no back-button loop.

Prerequisite: #618 (with its sibling #630), the backend taxonomy-type plumbing that supplies the type this guard checks. The guard has nothing to read until the type is a real value on the taxonomy-detail response.

Can be built alongside #616. #616 surfaces that same type on the frontend TaxonomyData and shares #618 as its prerequisite, so it is not a blocker for this ticket, it is a peer. Both consume #618's field. Coordinate on the field name and the Competency predicate's name so the two land compatibly, rather than sequencing this behind #616. #680 provides the page and route this guard wraps. Related: #663 (the entry point, only surfaced for Competency taxonomies, so normal navigation will not reach here for a non-Competency taxonomy; this guard covers direct or stale URLs).