Fix: Errors deploying jobs of type parameterized since 0.4.2

[ritesh-harihar]

Description
This PR fixes a regression where nomad-pack run could stop active child jobs (for example, dispatched or periodic runs) during reconciliation. The issue appeared after stale-job cleanup was introduced and affected deployments where child jobs inherit pack metadata.

Root Cause
Reconciliation in reconcile.go lists jobs by pack.deployment_name and treats jobs not in the current rendered root job set as stale. Child jobs created from a root pack job were included in that list and misclassified as stale, which caused unintended Deregister calls. The previous logic did not robustly distinguish root jobs from generated child runs.

Fix

• Tightened stale-job selection to skip child jobs before stop actions.
• Child detection now uses ordered signals:
  - ParentID (preferred),
  - pack.job metadata consistency (pack.job != job ID means child),
  - slash-shape fallback only when pack.job metadata is missing.(Currently slash-based child suffixes are hardcoded and used in nomad)
• Added nil-safety in the reconcile loop to avoid dereference risk on unexpected list entries.

Why this approach

• Avoids hardcoding only periodic-* / dispatch-* assumptions.
• Keeps behavior future-tolerant without adding extra Nomad API lookups.
• Preserves original stale-job cleanup intent for true removed root jobs.

ISSUE

Testing:

• Before fix:

• After fix:

Reminders

• Add CHANGELOG.md entry

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[jrasell]

Thanks for this @ritesh-harihar and it's looking good. I have a couple of comments I think are worth talking through before merging. The PR will also need a changelog.

[jrasell]

It is possible Nomad job IDs are configured with a number of slashes irregardless of whether they are dispatched. I am curious of your thoughts on removing this fallback altogether and relying on the ParentID and metadata identification? Are there cases where this wouldn't be enough?

$ nomad status
ID                      Type     Priority  Status   Submit Date
example/self/namespace  service  50        pending  2026-03-31T10:07:51+01:00

[ritesh-harihar]

“ParentID + pack.job " covers normal Nomad/nomad-pack behavior and removes slash-based false positives.

The remaining edge case is when both signals are absent/inconsistent in stubs; if we observe that in practice, we can add a targeted Jobs().Info check only for ambiguous entries to keep reconciliation safe.

So instead of calling Jobs().Info for every job, call it only for uncertain ones.

Pseudo flow:

if stub.ParentID != "" → child
else if pack.job exists:
pack.job != stub.ID → child
pack.job == stub.ID → root
else (ambiguous) → call Jobs().Info:
full ParentID != "" → child
else → root

But not sure if we really need this API call?

[jrasell]

LGTM; I think we just need a changelog entry before merging.

[ritesh-harihar]

LGTM; I think we just need a changelog entry before merging.

Updated the changelog.