Orchestrator 'local' provider: unresolved value leaks as [object Promise] into the Unity image tag

## What's happening

The \`Integration Tests\` workflow's \`AWS Provider Tests\` / \`K8s Provider Tests\` / \`Local Docker Provider Tests\` jobs (\`yarn vitest run "orchestrator-image" --no-file-parallelism\`) have failed on **every run for at least 15 days straight**, across every commit on \`main\` in that window - confirmed via \`gh run list --workflow="Integration Tests"\`, unrelated to any recent PR.

Real runtime output from a failing run (not a test assertion failure - this reaches an actual \`Orchestrator.run()\` call):

\`\`\`
Orchestrator platform selected local
Provider init timeout: undefineds
Orchestrator is running standard build automation
unityci/editor:[object Promise]-linux-il2cpp-3
Orchestrator failed: Build failed with exit code 1
\`\`\`

## Two distinct bugs here

**1. \`unityci/editor:[object Promise]-linux-il2cpp-3\`** - a Promise object is being interpolated directly into a template literal building a Docker image tag, instead of being awaited first. \`ImageTag\` (\`plugins/orchestrator/src/model/image-tag.ts\`) just stores whatever \`editorVersion\` string it's given - it isn't the bug itself, just where the bad value surfaces. The leak happens upstream, somewhere between an unresolved Unity-version lookup and \`new ImageTag(buildParameters)\` for the \`local\` provider strategy specifically (\`Orchestrator platform selected local\` prints right before this). I traced \`plugins/orchestrator/src/model/orchestrator/tests/orchestrator-image.test.ts\`'s \`Can create valid image from normal config\` test as the one matching the \`"orchestrator-image"\` vitest filter that constructs an \`ImageTag\`, but that specific test's own setup (\`UnityVersioning.read('test-project')\`, which is genuinely synchronous - confirmed by reading \`unity-versioning.ts\`) doesn't explain the leak on its own, so the actual unawaited call is more likely inside the \`local\` provider's own build-automation path (\`Orchestrator.run\` → \`Orchestrator platform selected local\` → \`unityci/editor:[object Promise]...\`), which I didn't have time to trace to its exact source line.

**2. \`Provider init timeout: undefineds\`** - \`plugins/orchestrator/src/model/orchestrator/orchestrator.ts:481\`, \`OrchestratorLogger.log(\`Provider init timeout: ${timeoutSeconds}s\`)\` - \`timeoutSeconds\` is \`undefined\` here. Possibly harmless (just a formatting bug, "s" instead of "Ns"), but worth checking whether a missing/undefined provider-init timeout has any real effect on provider startup behavior, or is purely cosmetic.

## Why this matters despite not blocking anything today

This exercises the same \`--provider-strategy local\`/\`local-system\` path documented in game.ci's own docs (\`game-ci orchestrate --provider-strategy local\`), so if this reaches a real invocation (not just the test), a local-provider orchestrated build would request a nonexistent Docker image tag and fail. It's also a CI check that's been red for 2+ weeks, which trains reviewers to ignore it - worth either fixing or explicitly marking non-blocking/quarantined so it stops being silent noise.

## Suggested next step

Trace the \`local\` provider's build-automation code path (not the CLI command handlers in \`plugins/orchestrator/src/cli/commands/\`, which I checked and look correct - \`await BuildParameters.create()\` then \`new ImageTag(buildParameters)\` synchronously) for wherever it resolves/re-resolves the Unity editor version for a \`local\`/\`local-system\` job, and confirm that resolution is awaited before being used to build an image tag string.

Confirmed pre-existing and unrelated to game-ci/cli#240–#246 (the embedded-assets/install-script/license-activation work merged 2026-09-04–07): this failure long predates all of those commits.

Start with plugins/orchestrator/src/model/orchestrator/orchestrator.ts and trace Orchestrator.run through the local provider build-automation path to new ImageTag, checking where UnityVersioning or another lookup is awaited. Run the orchestrator-image Vitest command and confirm local-provider runs no longer produce [object Promise] image tags. Also verify whether the timeout value at line 481 is cosmetic or affects startup behavior.

Written by the indexing model from the issue text.