[X-Guardian]

Description

The C#, Java, Java-gradle, and Python *-documentation examples are the critical-path tail of the examples CI matrix — they finish at ~25–29 min while every other example is long done. Almost all of that time is cdktn get generating provider bindings, and it runs fully serially. This PR lets it run in parallel, mirroring how go-documentation is already configured.

Why

Profiling the csharp-documentation job showed cdktn get took 504s of a 691s job — generating + JSII-compiling 6 provider bindings (aws and kubernetes dominate) one at a time. The serialisation is deliberate: these four examples pass --parallelism 1, because cdktn get defaults to --parallelism -1 (all providers concurrently), and the heavy providers need ~13–17 GB peak RAM together — more than a standard ubuntu-latest runner (16 GB) can hold without OOM. go-documentation already side-steps this: it runs on depot-ubuntu-24.04-16 with the default parallelism and finishes the same generation step in ~60s (17.6 GB peak).

So the throttle and the runner choice are two halves of one decision. Lifting the throttle requires the bigger runner, and the bigger runner is wasted while the throttle is in place. This PR changes both together for the four JSII-translated documentation examples.

Approach

1. Route the JSII-language documentation examples onto Depot runners in examples.yml. The runs-on selector was go-documentation-only (on depot-ubuntu-24.04-16); it now also routes csharp, java, java-documentation-gradle, and python documentation examples to depot-ubuntu-24.04-8. go-documentation stays on -16 (unchanged). typescript-documentation is intentionally excluded — TypeScript bindings aren't JSII-translated, so --parallelism doesn't apply and the job is already cheap (~226s).
2. Drop --parallelism 1 from the build script of the four examples (csharp/documentation, java/documentation, java/documentation-gradle, python/documentation), letting cdktn get fall back to its -1 default and generate all providers concurrently — matching go-documentation.

Measured impact (on the shipped depot-ubuntu-24.04-8 runners): csharp-documentation's cdktn get runs in 1m13s, down from 8m24s serial — a ~7× speedup — taking the job from ~11m31s to 4m21s. The other three are comparable: java-documentation get 1m24s (job 4m33s), java-documentation-gradle get 1m13s (job 4m29s), python-documentation get 1m08s (job 3m42s) — each down from ~11–13 min to ~3.5–4.5 min. The serial --parallelism 1 builds previously peaked at ~4 GB; running all providers concurrently peaks at 23–26 GB, which would OOM a 16 GB ubuntu-latest runner — confirming the throttle and the runner choice had to move together.

Right-sizing the runner — -8 vs -16: the change was first measured on depot-ubuntu-24.04-16 (16 vCPU / 64 GB), then re-run on depot-ubuntu-24.04-8 (8 vCPU / 32 GB) to avoid over-provisioning. Both work: get is only ~10–13s slower on -8 (fewer cores → slightly less compile concurrency), and peak RAM (23–26 GB) sits within the -8 tier's 32 GB with ~6–9 GB headroom. Per-run variance (~30–60s) exceeds the -8-vs--16 gap — at this provider count cores aren't the binding constraint — so the four examples ship on -8.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.