Mail Details Overview rebuilt on centralized state management

The Mail Details "Overview" screen has been re-engineered onto a single centralized form-state store instead of passing dozens of values manually between components. This is an internal architecture refactor that keeps the same visible features (sender/recipient, classification, status, resolution, read/unread toggle) while making the page more maintainable and reducing the bugs that come from scattered, duplicated state. The change has reached the QA environment.

The mail details page had grown to manage editing, saving, addresses, folders, priority, labels, statuses and read-state through long chains of props and many local component flags. That prop-drilling made the screen fragile and hard to extend: every component needed to know about every value, and keeping them in sync (especially across the sender and recipient address panels) was error-prone. A shared state layer was needed to consolidate this and make future changes safer.

End users see the same Overview workspace and behavior, so there is no new feature to learn. The benefits are stability and velocity: the read/unread toggle now updates optimistically and automatically rolls back with an error message if the server rejects it, and the sender/recipient panels share one consistent source of truth. For the product team, the cleaner foundation makes future enhancements to mail details faster and lower-risk.

• Added a new Zustand store mailOverview.store.ts (using immer and devtools) exposed through a React context provider, holding client/sub-client, sender/recipient address state, folders, priority, upload center, tracking number, labels, statuses, notes and a resetKey for re-initialization.
• Added immer@^10.0.3 as a dependency (package.json / pnpm-lock.yaml).
• Rewrote mails/[id]/page.tsx: split into an outer data-fetching component and an inner MailDetailsPageWithStore; edit/save state moved from local useState into the store.
• Refactored AddressComponent, ClassificationAndRouting, MailStatus, ProcessingInformation, ToBeResolved, MailOverviewDetails and MailOverview to read from the store instead of receiving props.
• Added a memoized ReadStatusToggle component with optimistic update, error rollback, and targeted cache invalidation (mailGrid, mails, inboxGrid, inboxStatusCount).
• Added a shared MAIL_OVERVIEW_EDITABLE_FIELD_CLASS styling constant for consistent editable-field appearance.
• Net ~1,449 additions / ~805 deletions across 14 files.

Medium. This rewrites the core mail details screen and the way its edit/save flow is wired, so regressions in editing, saving, address selection, or read-state are the main risk. Notably the Edit/Save/Cancel toolbar buttons on the Overview tab are commented out in this change, so inline editing entry points should be confirmed during QA. Mitigation: the refactor preserves the existing components and API calls, the read toggle has explicit error rollback, and the change is gated in QA before any production promotion.

• Open a mail's details page and confirm Overview, Documents, Activity Log, and Resolution tabs all load and switch correctly.
• Verify the read/unread toggle updates immediately, persists on refresh, and reverts with an error toast if the update fails (e.g. offline).
• Edit sender and recipient organization, department, contact, and addresses; confirm selections stay consistent and save correctly.
• Edit folders, priority, upload center, labels, tracking number, statuses, notes, postmark date and deadline; save and reload to confirm persistence.
• Confirm how editing is entered on the Overview tab given the Edit/Save/Cancel buttons were commented out; ensure no orphaned save path.
• Switch tabs mid-edit and confirm no stale state or unexpected reset; verify inbox grid counts refresh after read-state changes.