[BUG] Pipeline execution assumes child pipeline ID is always parent ID + 1 #1705

Describe the Bug

The client computes a Digital Twin's child GitLab pipeline ID as parentPipelineId + 1 instead of looking up the actual pipeline GitLab created. GitLab pipeline IDs increment globally across the whole project, not per trigger relationship, so any other pipeline created between the parent and its real child (a concurrent execution, retry, or scheduled job) shifts the sequence and makes this guess wrong.

When that happens, DTaaS polls, cancels, or fetches logs from the wrong pipeline, and can report an execution as failed or stuck while the real child pipeline is still running or has already succeeded. This affects Digital Twin executions, Measurement runs, and cancellation, since they all derive the child pipeline ID the same way.

This may particularly affect the e2e tests causing them to be flaky and requiring to be run in sequence rather than in parallel, which significantly slows down testing and development.

Steps to Reproduce

1. Start a Digital Twin execution (or a Measurement run) so a parent pipeline is triggered in GitLab.
2. While that parent pipeline is still running, trigger another pipeline in the same GitLab project, for example by starting a second execution, a manual pipeline run, or letting a scheduled pipeline fire.
3. Let the first parent pipeline finish so its real child pipeline is created and starts running.
4. Watch the execution status or logs for the first Digital Twin in DTaaS.
5. Observe that the reported status, logs, or cancel action correspond to whatever pipeline happens to sit at parentPipelineId + 1, not the actual child pipeline.

This is intermittent since it depends on pipeline ID interleaving, so it shows up most reliably under concurrent executions, parallel test runs, or busy shared GitLab instances.

Expected Behaviour

DTaaS should resolve the real downstream pipeline for a given parent pipeline (for example via GitLab's pipeline bridge/trigger job data), rather than assuming a fixed numeric offset. Status, log fetching, and cancellation should always act on the pipeline GitLab actually created for that execution.

Screenshots

-

Application Environment

• OS: Any
• Browser: Any
• DTaaS Release: 1.3.0 (main branch)

Additional Context

Root cause: childPipelineId = parentPipelineId + 1 arithmetic was used across the pipeline execution and measurement modules (parent/child status polling, cancellation, and log fetching). The fix replaces this with a lookup through GitLab's pipeline bridges, which expose the actual downstream_pipeline triggered by a parent pipeline.