Fix routing #954

Routing continues to be a nightmare in the gh-pages feature deployment. A very through anaylisis of the routing worfklow is needed. So a comprehesinve unifed approach can be enforced across all pages such as:

landing page
https://litlfred.github.io/sgex/ (also handle index.html)
https://litlfred.github.io/sgex/docs
https://litlfred.github.io/sgex/404.html

feature branch or main deployment such as:
https://litlfred.github.io/sgex/copilot-fix-549/ (also handle index.html)
https://litlfred.github.io/sgex/copilot-fix-915/docs
https://litlfred.github.io/sgex/copilot-fix-915/dashboard/litlfred/smart-ips-pilgrimage
etc.

there is no 404 for feature/main branch deployments. There is one 404 page. It should be deployed from the main branch and covers all 404 routing. behaviour is:

• It needs to handle cyclic redirects.
• if URL looks like is a feature/main deployment (so not /docs or /index.html or / or /404.html) and it is not already coming from a redirect from the landing page url for that deployment, then first try to redirect to the deployment landing page

when entering in a URL directly (and not viewing browsing the UI of the SPA) the site does not load the page as expected, rather it goes to the welcome page. when opening a direct link, the url should be processed to set all session storage variables (e.g. :profile, :repo, etc.). these should also be preserved in the URL itself. all of the url fragments, anchors #, and query params ? should be preserved in the URL when processing a directly entered URL to determine the page to display.

no branch names or page names should be hardcoded. everything should be handled dynamically and be optimistic in assuming branches / pages are deployed.

please describe a comprehsinve solution of how to make the routing work reliably. descirbe any change migration needed.

DO NOT IMPLEMENT. I want to review proposal before implementation.