Handle runtime error when attempting to access dns_zone on nil workspace_agent_config
MR: Pending
<!--
The first line of this issue description must be one of the following:
1. `MR: Pending`
2. `MR: <MR link with trailing +>`,
3. If there are multiple MRs:
```
MRs:
- <MR 1 link with trailing +>`
- <MR 2 link with trailing +>`
- ...
```
4. `MR: No MR`
...and the first description line of the MR should be `Issue: <Issue link with trailing +>`
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#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
We received a [sentry report](https://new-sentry.gitlab.net/organizations/gitlab/issues/1247466/?project=3&query=is%3Aunresolved+feature_category%3Aworkspaces&referrer=issue-stream&statsPeriod=14d&stream_index=0) of a workspace model being associated to a `nil` `workspace_agent_config` when attempting to build the workspace URL (which is dependent on the config's `dns_zone`).
we believe this error to be as a result of a temporary intermittent state, as the workspace in question was `terminated` and this does not occur frequently in the logs.
### proposed fix
We should make the URL method fail-safe and make it return an empty string if the `agent_config` is not present
### follow-ups/open questions
- Should we dig more into this intermittent state that allows for such errors ?
- Should we always be in the habit of doing this if `nil` returns empty checks ?
- Add this behaviour in other possible places it could occur ?
## Acceptance Criteria
- [ ] Return an empty string in the URL method if the agent config is missing
## Technical Requirements
## Design Requirements
## Impact Assessment
## User Story
<!-- 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://handbook.gitlab.com/handbook/engineering/development/dev/create/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