scheduler(system): Fix potential panic in deployment handling.

[jrasell]

When a system job deployment is successful and a task group has no feasible candidate nodes, the task group's deployment state is set to nil in the mapping. If the deployment is persisted to state, because the job has multiple task groups and at least one results in successful placements, a subsequent evaluation likely triggered by a recovering node will look up the previous deployment state. It was at this point, the scheduler was not correctly handling the nil object.

Another option could be to ensure the state write never includes a nil deployment object for a task group. It would require more work in upsert handling, so I feel this is the right approach as it's defensive and will always work.

Links

Jira: https://hashicorp.atlassian.net/browse/NMD-1266
Closes: #27567

Contributor Checklist

• Changelog Entry If this PR changes user-facing behavior, please generate and add a
  changelog entry using the make cl command.
• Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
  ensure regressions will be caught.
• Documentation If the change impacts user-facing functionality such as the CLI, API, UI,
  and job configuration, please update the Nomad product documentation, which is stored in the
  web-unified-docs repo. Refer to the web-unified-docs contributor guide for docs guidelines.
  Please also consider whether the change requires notes within the upgrade
  guide. If you would like help with the docs, tag the nomad-docs team in this PR.

Reviewer Checklist

• Backport Labels Please add the correct backport labels as described by the internal
  backporting document.
• Commit Type Ensure the correct merge method is selected which should be "squash and merge"
  in the majority of situations. The main exceptions are long-lived feature branches or merges where
  history should be preserved.
• Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
  within the public repository.

[tgross]

This patch seems fine but this same code path came up in #27382 as well. It seems to me that we shouldn't be touching the deployment at all if it's terminal, and that this is where the underlying bug is. I've been looking at that block of code the last week or so and don't quite understand why we're doing that, unfortunately.

LGTM but let's chat about whether there's a more comprehensive fix too.

[tgross]

@jrasell I think #27605 and #27604 cover the remaining concerns we had about this code path, so this should be good-to-go.