UX: decide what a path selector is, then build or drop it

Part of the UX backlog. Raised on 2026-06-11 against the old static portal; needs re-thinking for course-v2.

The original idea was a "path selector" on the portal so a reader could pick a route through the material rather than reading the catalog top to bottom.

This one needs a decision before it needs code. The catalog in course-v2 already lists tracks and levels, so it is not obvious what a path selector adds on top. Candidate readings:

• choose PHP vs ExApp up front and hide the other track
• a recommended order across tracks, levels and standalone modules ("start here, then this")
• goal-based entry points, e.g. "I want to publish an app to the App Store" → a curated subset

Scope

Decide what a path actually is, then implement. If the answer is "the catalog is enough", close this as not needed — that is a valid outcome.

Where

components/CatalogClient.tsx, and content/course-manifest.json if paths need declaring as data.

Done when

Either a path selector exists and is driven by the manifest, or this issue is closed with the reasoning recorded.

Start by reading components/CatalogClient.tsx and content/course-manifest.json to understand how course-v2 currently exposes tracks and levels. Decide whether a path adds value beyond the catalog, then either implement a manifest-driven selector or record the reasoning for closing the issue as unnecessary. Done means the selector works from manifest data, or the decision and rationale are documented.