<!-- IssueSummary start --> <details><summary>Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.</summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=457760) </details> <!-- IssueSummary end --> MR: Pending ## Description We need to explore the UX around moving away from the GitLab agent configuration file and into some UI element such as the agent administration section in `Operate > Kubernetes clusters` as proposed in https://gitlab.com/groups/gitlab-org/-/epics/11631#note_1871248508 The initial field to drive this location in the UI will be `max_hours_before_termination_limit`. - See https://gitlab.com/groups/gitlab-org/-/epics/14186+ for overview and more context - See [Related Issues and MRs section in that epic](https://gitlab.com/groups/gitlab-org/-/epics/14186#related-issues-and-mrs) for related issues and MRs ## Acceptance Criteria * [ ] Adds new page for "Workspaces agent configuration settings" * [ ] Ensure that the "unset" functionality is supported. * [ ] Adds necessary GraphQL API support and tests * [ ] Fully exercise new behavior in `request` and `feature` level integration tests. ## Design Requirements Adds a new page to view/edit workspace agent configuration settings. This new page will be accessible via a new `Workspace agent configuration settings` option under the `Actions` menu in the agent row of the Kubernetes cluster agents list:  ### "Unsetting" behavior We also need to define how users can "unset" a setting, and let it return to the default, non-overridden value. See this related discussion on the UX/design around this in the internal Cascading Settings meeting notes: https://docs.google.com/document/d/1_wnE_UM3snxoY0SJKn8Ol4GT1NBXHQSdmkXNToxIZv8/edit#bookmark=id.hc1dfs6o4dw <!-- 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 -->