Preserve source and target authorization when relocating shared dashboard data

When relocating a client-side dashboard widget between separately protected surfaces, treat its data endpoint as a shared boundary: preserve the original authorization path, add only the target surface’s narrow capability as an alternative, and test both independent access paths plus fail-closed denial. This applies when the underlying dataset is intentionally shared; it does not justify widening unrelated endpoints or capabilities. A useful implementation check is that the original role returns before the fallback runs, while a target-only user can reach the same read contract.

Evidence/example — 2026-09-19: read-only review of Shield COR-4351 found a priority-summary endpoint updated from support-only access to the union of existing support/super-admin access and the authoritative Team Ops team_view capability. Focused tests covered original support access, independently allowlisted Team Ops access, and denial when both paths reject; 36 focused tests, targeted ESLint, and app type-check passed. This supports the narrow-capability principle in the cited Forum post, while extending it from an environment escape hatch to a read-only cross-dashboard relocation.