fix: [UIE-10603] - Increase profile preferences reliability

[abailly-akamai]

Description 📝

We keep receiving reports of preferences in Cloud Manager being randomly reset.

This PR hardens Cloud Manager’s profile preferences flow so we stop silent destructive PUTs.

Changes 🔄

• Primary nav: Removed the effect that called accordionClicked / updatePreferences on load when collapsedSideNavProductFamilies was unset. Accordion open state for “no saved preference” is now derived in UI from the active route, so we don’t persist nav state on mount and trigger extra merge traffic.
• ensureQueryData when mutating preferences: we want to make sure we have up to date data before PUT

Still a potential risk:
Concurrent PUTs (two updates in flight) can still “last write wins”; we could add a global queue, which is something I will consider once this endpoint is being ported to ORION.

Scope 🚢

Upon production release, changes in this PR will be visible to:

• All customers
• Some customers (e.g. in Beta or Limited Availability)
• No customers / Not applicable

How to test 🧪

Reproduction steps

Hard to reproduce, but reported on production accounts by internal and external users.

Verification steps

• Confirm behavior of Primary Nav when no sidebar category stored in the preferences (should still open the category on initial landing, but does not store it in the preferences until a category header or category item is actually clicked).
• Confirm setting of preferences and their persistence at /profile/preferences
• Confirm no reset of preferences after logout/log back in
• Confirm no regressions on flows relying heavily on preferences (ex: ACLP)

Author Checklists

As an Author, to speed up the review process, I considered 🤔

👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support

• I have read and considered all applicable items listed above.

As an Author, before moving this PR from Draft to Open, I confirmed ✅

• All tests and CI checks are passing
• TypeScript compilation succeeded without errors
• Code passes all linting rules

[abailly-akamai]

IF

1. The mutation fails — the promise rejects with PREFERENCES_MERGE_FAILED (same shape as other API errors: [{ reason: '...' }]).
2. onError runs — preferences query is invalidated, so the client refetches and tries to realign with the server.
3. Nothing is PUT from this attempt — we never call updateUserPreferences with a bad merge base, so we avoid the catastrophic case “spread undefined / wrong shape and replace the blob with almost nothing.”

[abailly-akamai]

I think this one has always been questionable and a potential culprit for the faulty reset

[linode-gh-bot]

Cloud Manager UI test results

🔺 1 failing test on test run #9 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
1 Failing	901 Passing	11 Skipped	41m 46s

Details

Failing Tests
	Spec	Test
❌	object-storage.e2e.spec.ts	Cloud Manager Cypress Tests→object storage end-to-end tests » can update bucket access

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/objectStorage/object-storage.e2e.spec.ts"

[bnussman-akamai]

Wondering if this is necessary now that we use ensureQueryData.

Suggested change

	if (!isPreferencesMergeBase(existingPreferences)) {
	throw PREFERENCES_MERGE_FAILED;
	}

Here, existingPreferences comes directly from the API, which (I think) has pretty strict validation, meaning it will always return a JSON-shaped object { ... }. If something goes wrong fetching initial preferences, ensureQueryData will throw so I don't think this chunk of code will ever be hit. Maybe we can remove it?