chore: Remove storage functionality from Delegation Controller

[jeffsmale90]

Explanation

Delegation "storage" was added the the Delegation Controller to support Remote Mode. Because this feature is no longer in development, the storage functionality is not used.

This PR removes entirely the storage functionality from the controller.

Background

#8286 aimed to migrate code from clients into the controller, but as this storage functionality is unused, it was decided to remove the functionality completely. Followup PRs will be opened in the clients to update the controller, and remove the remaining boilerplate, including awaitDeleteDelegationEntry function.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Breaking change: removes persisted delegations state plus the store/list/retrieve/chain/delete public APIs and related messenger action types, so downstream clients depending on them will fail to compile or lose behavior. Functional risk is otherwise contained since signing (signDelegation) remains unchanged aside from dropping AccountsController integration.

Overview
Refactors @metamask/delegation-controller into a signing-only controller by removing the persisted delegations state and deleting the storage/query APIs (store, list, retrieve, chain, delete) along with their exported messenger action types.

This also removes the package’s dependency on @metamask/accounts-controller (and related tsconfig refs), simplifies controller metadata/state to an empty object, and updates tests/docs/changelog/eslint suppressions accordingly.

^{Reviewed by Cursor Bugbot for commit 3b0f67f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mj-kiwi]

LGTM

[cryptodev-2s]

This controller is now becoming stateless, should we make it a service instead ? we may want to just mark this controller as deprecated and create a new service instead. (then we just archive it one it's replaced in clients ?)

[jeffsmale90]

This controller is now becoming stateless, should we make it a service instead ? we may want to just mark this controller as deprecated and create a new service instead. (then we just archive it one it's replaced in clients ?)

@cryptodev-2s we are likely going to re-centralise a generalised storage into this controller, so it's stateless for now, but will not be for ever.

If we end up not doing that, I think we can refactor to a service.

[cryptodev-2s]

Nit: We should consider adding in the changelog that clients should not anymore delegate AccountsController:getSelectedAccount to the messenger controller.
Good to go if you're planning to update the clients soon.