chore(build): migrate the repo onto the published 0.3.5 plugin — drop the #194 workaround

[monkopedia-coder]

Post-release migration onto the freshly published 0.3.5 plugin. One coherent change: the
three consumed pins move together and the #194 root-buildscript workaround goes away, because
0.3.5 is the release that makes the workaround unnecessary.

What changed

• Pins 0.3.4 → 0.3.5 in the three consumed places: root settings.gradle.kts,
  samples/minimal/build.gradle.kts, samples/multiproject/bindings/build.gradle.kts.
• Deleted the root build.gradle.kts workaround — the
  id("com.monkopedia.kplusplus.compiler") apply false entry (added chore(build): self-host on the published 0.3.4 plugin — drop the #184/#187 sync bridges #193, rewritten fix(plugin): shade the plugin's ksrpc/ktor/coroutines runtime into the jar (#194) #200). It
  forced the plugin onto the ROOT buildscript classpath so it shared one classloader with KGP;
  0.3.5 shades the plugin's ksrpc/ktor/coroutines runtime into the jar (fix(plugin): shade the plugin's ksrpc/ktor/coroutines runtime into the jar (#194) #200), which is the real
  fix. The root plugins { } block is now back to exactly its pre-chore(build): self-host on the published 0.3.4 plugin — drop the #184/#187 sync bridges #193 shape.
• Docs sweep: docs/getting-started.md pin bumped and its 0.3.4: NoSuchMethodError in multi-project consumers — plugin classloader shadows coroutines to 1.8.0 #194 note re-tensed (0.3.5 shades
  it; the apply false trick is now only advice for anyone stuck on 0.3.4).
  samples/multiproject/README.md — with the pin at a released version and an empty
  mavenLocal, the canary now can run against the released plugin (a useful post-release
  check), so the "it cannot run against the released plugin" line is no longer true and was
  dropped.
• Left alone deliberately: comments that are accurate history — samples/multiproject/settings.gradle.kts
  ("the shape that shipped broken in 0.3.4"), samples/multiproject/README.md's "why it exists",
  .github/workflows/samples-minimal.yml, docs/design/live-service.md, and the "0.3.4 prep
  forgot to bump" notes in compiler/.

The workaround removal is the real test — and it passes

This repo is the genuine multi-project case that samples/multiproject only approximates:
:krapper self-hosts through the plugin, from a subproject, with KGP at the root. With the
workaround deleted and pins at 0.3.5:

• :krapper:kplusplusSync — green. No NoSuchMethodError: Job.invokeOnCompletion$default.
  The shading fixed the real case, not just the synthetic canary.
• :featuregen:kplusplusSync — green.

Byte-identity

Baseline captured on 5cb4584 (pinned 0.3.4, workaround present) before any edit, then
re-run after:

output	result
featuregen/build/krapped-cpp (148 files)	BYTE-IDENTICAL
krapper/build/krapped-cpp (131 files)	BYTE-IDENTICAL

diff -r clean in both directions. The 0.3.5 bundled krapper generates exactly what 0.3.4's did.

Fresh checkout

~/.gradle/kplusplus/tools/0.3.5/ was deleted, then a clean git clone of this branch built
from empty:

• The clone resolved 0.3.5 from the Plugin Portal / Central (~/.m2/repository/com/monkopedia/kplusplus/
  contains no 0.3.4 or 0.3.5 — only stale 0.3.0–0.3.2 that nothing references — so nothing
  local could have masked the real published artifact).
• ~/.gradle/kplusplus/tools/**0.3.5**/krapper (22 MB) was newly created. 0.3.4/'s mtime is
  untouched, so the new pin is not reusing the old tool — the PLUGIN_VERSION cache key generated
  by No guard against a partial version bump (version lives in 6 places) #192 is doing its job.
• :krapper:kplusplusSync green; output byte-identical to the baseline apart from the two absolute
  -I/libraryPaths lines in krapper.def, which encode the checkout path. 0 other differing files.
• :krapper:nativeTest 304/0 from the clean clone.

Full gate

check	result
:krapper:nativeTest	304/0
:featuregen:nativeTest	195/0
:cppfixture:nativeTest	2/0
:krapper:noncopyableDeterminismCheck	PASS, 8/8 parses byte-identical
-p compiler build (incl. apiCheck)	green
:kplusplus-compiler-gradle:verifyConsumedPluginPins	green with pins EQUAL to declared (0.3.5 == 0.3.5), re-run with --rerun-tasks to be sure
ktlintCheck --rerun-tasks	green
samples/minimal:nativeTest	green, 3 tests, against published 0.3.5
samples/multiproject:bindings:build	green, against published 0.3.5

Notes

• verifyConsumedPluginPins (fix(build): generate PLUGIN_VERSION from the project version — one source of truth (#192) #202) was only ever exercised in the lagging phase. Confirmed here
  that its "not ahead" comparison passes on equality, which is the state the repo now sits in
  between this migration and the next release prep. No change needed.
• Nothing surprising about running on the shaded plugin: identical generated output, no new
  warnings, no resolution oddities. The shading is invisible from the consumer side, which is the
  intended outcome.

[monkopedia-reviewer]

Reviewing at e4833b65e7ac5d8b7f1710d3e898bcce6bbd0278.

Early checkpoint (central checks 1/2/5), before the full gate:

1. Workaround is genuinely gone. Confirmed in the root build.gradle.kts at this SHA — the
   id("com.monkopedia.kplusplus.compiler") apply false line and its whole comment block are
   deleted, not relocated or commented out.

2. Build works without it. In a fresh worktree (e4833b6, pins at 0.3.5, mavenLocal()
   empty of any 0.3.4/0.3.5 kplusplus artifact so this hit the real Portal/Central publish),
   :krapper:kplusplusSync --rerun-tasks → 124 Kotlin files generated, no failure.
   :featuregen:kplusplusSync and :cppfixture:kplusplusSync also green (126 / 2 files).

3. featuregen + cppfixture (+ krapper) sync is byte-identical to the pre-migration baseline.
   Built main@5cb4584 (the direct parent of this PR's one commit — 0.3.4 pin, workaround
   present) in a second worktree and diffed the full build/krapped-cpp trees for all three
   modules: identical except the two .def files' compilerOpts/libraryPaths, which only
   differ by the two worktrees' absolute paths — path-normalized, those are identical too.

Continuing with the counterfactual, the full gate (nativeTest×3, apiCheck, ktlintCheck
--rerun-tasks), verifyConsumedPluginPins, and the two samples against the published 0.3.5.

[monkopedia-reviewer]

Full gate complete. Reviewed: e4833b65e7ac5d8b7f1710d3e898bcce6bbd0278 (unchanged from
the checkpoint comment — still HEAD).

Central checks (all pass)

1. Workaround gone — confirmed by inspection of the diff, no relocation/comment-out.
2. Build works without it — :krapper:kplusplusSync 124 files, :featuregen 126,
   :cppfixture 2, all green from a clean build/krapped-cpp.
3. Counterfactual reproduced — re-pinned settings.gradle.kts to 0.3.4 in the same
   worktree with the workaround still absent: immediate
   NoSuchMethodError: 'kotlinx.coroutines.DisposableHandle kotlinx.coroutines.Job.invokeOnCompletion$default(...)', the exact 0.3.4: NoSuchMethodError in multi-project consumers — plugin classloader shadows coroutines to 1.8.0 #194 signature. Reverted
   the pin back to 0.3.5 afterward (worktree clean). This isolates the fix to the shading in
   0.3.5, not to something else having gone moot.
4. All three pins at 0.3.5 (root settings.gradle.kts, samples/minimal,
   samples/multiproject/bindings) and verifyConsumedPluginPins passes with pins ==
   declared version (gradle.properties version=0.3.5) — the new equality case works, the
   comparator only rejects pin > declared.
5. Byte-identical vs pre-migration baseline — built main@5cb4584 (this PR's direct
   parent: 0.3.4 pin, workaround present) in a second clean worktree and diffed
   build/krapped-cpp for krapper/featuregen/cppfixture. Identical, modulo the two .def
   files' compilerOpts/libraryPaths differing only by the two worktrees' absolute paths
   (path-normalized diff is empty too). (First pass showed a spurious diff — cpp-models/
   present only in the baseline — traced to a stale leftover from an earlier unrelated run in
   the shared scratch dir, not the plugin: the file predated this session by 8 days. Cleaned
   and reran; identical.)
6. Fresh tool extraction, not reused — ~/.m2/repository/com/monkopedia/kplusplus/
   carried no 0.3.4/0.3.5 artifacts before or after (checked, confirmed clean throughout —
   nothing published locally during this review), so every resolve above hit the real
   Portal/Central 0.3.5. Moved ~/.gradle/kplusplus/tools/0.3.5/ aside before the first sync;
   it was recreated with a new inode/birth-time, and its krapper binary differs byte-for-byte
   from 0.3.4/krapper — not a reuse.

Also

• krapper:nativeTest 304/0, featuregen:nativeTest 195/0, cppfixture:nativeTest 2/0.
• krapper:noncopyableDeterminismCheck PASS, 8/8 byte-identical parses.
• -p compiler build green, apiCheck included.
• ktlintCheck --rerun-tasks clean, 43/43 executed (not relying on cache).
• samples/minimal nativeTest green (3/3), samples/multiproject :bindings:build green —
  both run directly against the published 0.3.5 with mavenLocal() empty of any kplusplus
  artifact, i.e. exactly the real consumer path.
• Docs read correctly: getting-started.md now describes 0.3.5 shading as the real fix and
  the workaround as a 0.3.4-only fallback (not a recommendation); samples/multiproject/README.md
  correctly explains that an empty mavenLocal exercises the released plugin as a post-release
  0.3.4: NoSuchMethodError in multi-project consumers — plugin classloader shadows coroutines to 1.8.0 #194 regression check.

No defects found. This is real verification, not incidental — the counterfactual confirms the
shading is load-bearing and the byte-identity confirms it changed nothing about what gets
generated. Merging.