Investigate how to show workspace is no longer usable once default resources of the agent are reduced
MR: Pending
<!--
The first line of the MR must be one of the following:
1. `MR: Pending`
2. `MR: <MR link with trailing +>`,
and the first description line of the MR should be `Issue: <Issue link with trailing +>`
3. `MR: No MR`
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs
-->
<!--
The following sections should be filled out as part of the refinement process before the issue is prioritized.
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting
-->
## Description
The following discussion from !139209 should be addressed:
- [ ] @cwoolley-gitlab started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139209#note_1706489874): (+1 comment)
> **observation (non-blocking)**: When the max resources are lowered in the config and the workspace is auto-restarted, if the requested resources exceed the new lower max limits in the agent config, _**the `actual_state` of the workspace is left in `Starting` actual state with a spinner, and it is unusable, even though there's no indication to the user that the workspace will never start again unless the max limits are increased again in the agent config**_.
>
> Nothing can be done with the workspace except terminate it. The only option to keep working is to start a new workspace with lower resource requests which are under the new agent max limits, which would lose .
>
> This isn't a good UX, we should probably create an issue to follow up on this to make the experience better.
>
> This should probably also be tied to the existing issue/epic to provide an audit log/event UI for workspaces (e.g. https://gitlab.com/gitlab-org/gitlab/-/issues/414897+), and or the admin UI work (https://gitlab.com/groups/gitlab-org/-/epics/10571+)
>
> cc @ericschurter @tvanderhelm
## Acceptance Criteria
TODO: Fill out (required)
- [ ] [Describe what must be achieved to complete this issue.]
- [ ] [Describe another requirement needed to complete this issue.]
- [ ] [Add additional acceptance criteria as needed.]
## Technical Requirements
TODO: Fill out or delete
[If applicable, please list out any technical requirements for this feature/enhancement.]
## Design Requirements
TODO: Fill out or delete
[If applicable, please provide a link to the design specifications for this feature/enhancement.]
## Impact Assessment
TODO: Fill out or delete
[Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.]
## User Story
TODO: Fill out or delete
[Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.]
<!-- Replace with other type, e.g. bug or maintenance, if appropriate -->
<!-- Replace with other subtype if appropriate -->
<!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process -->
<!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->
issue