Make service mode a first-class Sample App onboarding path

[rmcdaniel]

The Sample App has a polished embedded-Laravel quickstart and a comprehensive standalone PHP/Python/Rust stack under polyglot/, but the service-mode implementation reads as a conformance harness rather than an evaluator-facing product path. A Laravel user exploring polyglot execution should not have to discover test infrastructure or downgrade to a bare protocol example.

Keep embedded mode simple and add an equally direct service-mode journey built from the existing published Server and SDK artifacts.

Acceptance criteria

• The top-level onboarding presents two clear runnable paths: embedded Laravel and service mode. Neither is described as the lesser or legacy option.
• Service mode starts from the Codespace with one memorable command and reuses the prepared development image; it does not rebuild SDK/runtime toolchains.
• The first service-mode example uses the framework-neutral PHP SDK with its Laravel bridge, dependency injection, logging, worker command, and test fake rather than a bare standalone script.
• The path starts a workflow, executes a PHP activity, executes one cross-language activity through a Python or Rust worker, waits for a result, and links to the matching Waterline run.
• Beginner-facing output explains what started and where to inspect it without exposing conformance-matrix terminology.
• Embedded and service-mode examples use distinct isolated Compose state and can be run repeatedly without workflow-ID collisions or manual cleanup.
• All package and image versions resolve from the current supported 2.0 train; no stale RC number is copied into the onboarding instructions.
• A clean Codespace browser/terminal smoke proves both paths from documented commands and retains startup/result timing evidence.

Close only after a first-time-user smoke has completed both documented paths from a fresh Codespace.

[rmcdaniel]

Fresh evaluator evidence from a new Codespace confirms the prebuilt environment now supplies Rust, Cargo, and dw, and a Rust workflow plus activity completed against a managed Cloud namespace. The remaining first-run gaps mean this issue is not complete yet:

• the checked-in Rust worker still resolves durable-workflow 2.0.0-rc.5 while the current crate is 2.0.0-rc.11;
• the evaluator had to inspect the conformance worker instead of finding one obvious Rust Cloud entrypoint;
• dw workflow:start failed against the namespace runtime URL during /api/cluster/info discovery, forcing raw HTTP;
• the raw HTTP fallback required a control-plane version header that was not present in the quickstart path.

The CLI transport defect is isolated in durable-workflow/cli#18. The cross-repository Rust docs, current-version, and sample journey work is tracked in durable-workflow/.github#87. Completion here still requires the documented fresh-Codespace journey to work without source inspection.

[rmcdaniel]

Consolidated into #41; the full acceptance criteria are retained in that root issue.