Plan a multi-file migration before Copilot Edits touches a single file in the working set

I want to migrate the class-component + Redux connect() pattern to function components with hooks and the existing useAppSelector/useAppDispatch hooks using Copilot Edits, working from an
explicit file working set rather than letting Copilot decide on its own which files belong in this
change. Before adding a single file to the working set or proposing an edit, produce a plan and
wait for my approval.

WORKING SET
Every component under components/dashboard/ plus dashboard/types.ts — 15 files total.

MUST NOT BREAK
The memoized selectors in dashboard components must not re-render on every store update — that performance behavior is load-bearing on the live dashboard.

PLAN FORMAT
1. For every file in the working set, state the specific change it needs — not 'update as
   needed,' since Edits proposes a diff per file in the working set and a vague plan entry
   produces a diff with no clear standard to check it against.
2. Order the files so a shared or foundational file — a type definition, a config value, a base
   pattern the others extend — is migrated before the files depending on it, and explain why that
   order avoids a broken intermediate state where a dependent file has already been migrated
   against a shape the foundational file has not actually adopted yet.
3. Name one file from the working set to migrate first as a pilot, and state exactly what
   reviewing that one file's diff should tell me about whether the overall approach for the rest
   is right, before any other file in the set is touched.
4. For each item under MUST NOT BREAK, name which specific file's migration in the working set
   could threaten it, and how the plan avoids that — a generic reassurance that nothing important
   will break gives nothing to check the actual diffs against later.

After I approve the plan, add only the pilot file to the working set and propose its diff. Stop
there. Do not add the remaining files to the working set until I have reviewed that first diff and
told you to continue.

Migrate DashboardSummaryCard.tsx first — it is the smallest component using the pattern and appears on the lowest-traffic page.

CONSTRAINTS
- Review every proposed diff in the working set individually before accepting it — do not accept
  the whole working set's changes in one action just because the first two files you checked
  looked right; a working set can include a file whose diff was generated correctly in isolation
  but is wrong in combination with an adjacent file's diff that changed the same shared interface.
- If, partway through, a file outside the original working set turns out to need a change for the
  migration to actually hold together, stop and say so explicitly rather than silently adding it to
  the working set and folding its diff in with the rest — an unannounced scope expansion in a
  migration is exactly the kind of change that gets missed in review because nobody was told to
  look for it.