CCOR-13193 - adding test run against oss server in ci

[chrishagglund-ship-it]

Adds a second integration-test CI job that runs the suite against plain Conductor
OSS, alongside the existing authenticated run against the shared Orkes dev server.

scripts/docker-compose-oss.yaml brings up Conductor OSS + Postgres + httpbin;
scripts/run-integration-oss.sh runs the same stack locally.

Orkes-Enterprise-only surface (Authorization, Secrets, Schema, Service Registry,
metadata/scheduler tags) is gated behind CONDUCTOR_SERVER_TYPE=oss and skips on
OSS. The Signal API tests do run on OSS, using WAIT-based fixture variants
(complex_wf_signal_test_oss and friends) — YIELD is Orkes-only, so the existing
fixtures never reach a signalable state there. A few call sites need an OSS-specific
path rather than a skip (archiving on delete, the missing /workflow/{id}/status,
create-with-overwrite); each is gated on OSS on purpose, so the Orkes path still
fails if the real behaviour regresses.

Requires the E2E_TEST_OSS_CONDUCTOR_VERSION org variable, with a repository
access policy that includes this repo. The new job fails fast if it can't resolve
an image tag.

Also fixes three latent bugs in the existing Orkes run

Running against a fresh, single-tenant server surfaced these. All three affect the
integration-test job too, not just the new one:

1. test_async.py was clobbering another suite's task def — it registered a bare
   TaskDef under python_integration_test_task, the name
   test_workflow_execution.py runs real workflows against. Those two run as
   concurrent CI jobs against one server, so last writer won, and a bare def gets the
   server's default 3600s responseTimeoutSeconds — so a stalled worker held the task
   for an hour and the workflow sat IN_PROGRESS. It now registers its own def instead.
2. run_workflow_execution_tests never registered its task def —
   generate_tasks_defs() was dead code, so the def was whatever another suite left
   behind. Registering it sets response_timeout_seconds=2 (see 1) and makes the suite
   work on a fresh server.
3. The Signal API tests signalled before the workflow was parked —
   _wait_for_blocking_task matched any in-flight task, but the outer SUB_WORKFLOW
   flips to IN_PROGRESS before the nested workflow reaches its blocking task, so the
   signal raced the real block (intermittent "Expected BLOCKING_TASK, got None" / 404
   "Found no blocked task"). It now descends into running sub-workflows and matches
   only a non-terminal WAIT/YIELD task.

Also

• Server-flavour checks route through one is_oss() helper instead of 9 open-coded
  env reads, 4 of them inverted.
• test_task_metadata_service.py gains a tearDownClass — its defs used to be left
  behind, so re-runs hit "already exists".
• Fixture owner emails use the test@conductoross.io placeholder csharp-sdk settled
  on for this ticket, not real employee addresses.
• run-integration-oss.sh pulls the image unconditionally so a cached latest isn't
  reused; OSS health wait 120s → 180s; workflow_dispatch gains an
  oss_conductor_version input.