fix(background): scope suspended-run supersede to the submitting session (release-1.11.4) (#14615)

* fix(background): scope suspended-run supersede to the submitting session

A background submit for a flow cancelled EVERY suspended run of that flow and
user, so a second caller's POST /api/v2/workflows silently cancelled the first
caller's HITL pause even under a completely different session_id. A flow could
therefore hold only one pending human-input request at a time, which makes it
unusable as a shared, multi-tenant background endpoint.

Scope supersede_suspended_runs to the submitting run's effective session
(session_id, falling back to the flow id — the normalization the runner already
applies to the stream thread_id). A rerun still replaces the stale pause of its
own session/thread; SUSPENDED runs of other sessions stay untouched. Another
user's pause is still never touched and running jobs are still never superseded.

A stale run's session is read back off its persisted row inside the DB session
scope (job_metadata['request']['session_id'], or the flat
job_metadata['session_id'] legacy rows carry, mirroring _reconstruct_request),
so the JSON column is never read off a row detached from its session.

Fixes #14599

Co-authored-by: lorenzozanee <wyz0707@proton.me>

* test(alembic): resolve the upgrade-from-main baseline at the fork point on release branches

test_upgrade_from_main_branch upgraded a DB to origin/main's alembic head using
the BRANCH's version directory. On a PR based on a release branch that head does
not exist there — release-1.11.4 predates a3f8b1c9d7e2 — so the test could only
raise "Can't locate revision identified by 'a3f8b1c9d7e2'". It fails that way on
a pristine release-1.11.4 checkout with no changes at all; this PR only surfaced
it because the workflow's path filter covers services/background_execution.

Fall back to main's head at the fork point (git merge-base HEAD origin/main) when
main's tip head is not among the branch's own revisions. Main-based PRs are
unaffected (the tip head is present, so it is used as before), and a branch that
DELETES a migration main has still fails: that revision exists at the fork point
too, so the fallback cannot skip it away.

---------

Co-authored-by: lorenzozanee <wyz0707@proton.me>