Deferred from #586: graph-link pruning + ga_standards filtering for per-user resource selection

Follow-up to #586 (per-user resource selection), tracking the two pieces deliberately
deferred from that work so the core loop could land first. Confirmed with @northdpole as
out of scope for #586 and appropriate as a separate follow-up.

1. Graph-link pruning on CRE pages

Server-side filtering currently applies to the standards list (/rest/v1/standards).
It does NOT prune non-selected standards from the links shown on an individual CRE page —
so a user who filters out (say) SAMM still sees SAMM links when they open a CRE. Decide and
implement whether a user's selection should also prune standard-links off CRE nodes in the
graph views (root_cres / text_search / find_cre), and how (hide the link vs. hide the
node). Flagged as a UX-sensitive call — easy to surprise people on a CRE page.

2. ga_standards filtering + paired frontend bypass

/rest/v1/ga_standards feeds the gap-analysis dropdowns. Filtering it by a user's saved
selection would narrow the GA inputs, so it was left out of the server-side filter PR to
avoid silently shrinking the dropdowns. Completing it needs the server-side filter plus
the paired frontend change to pass ?all=true where GA should span all eligible standards.

Context

Core #586 loop is complete and merged: user + selection persistence, GET/PUT
/rest/v1/user/resources, /rest/v1/standards server-side filter (?all=true bypass), the
MyOpenCRE selection UI, and the concurrency-safe write with the OpenCRE-always-included
invariant. This issue tracks only the two deferred extensions above.

Start with the /rest/v1/standards and /rest/v1/ga_standards entry points, then trace filtering in the root_cres, text_search, and find_cre graph views and the paired frontend calls. Review the existing ?all=true bypass and decide whether filtered standards hide links or nodes. Done means graph-link behavior is implemented and GA requests pass ?all=true where they must span all eligible standards.