Add a codegen extension SPI, with a transformPath hook

[kubukoz]

Replaces #23, which added a static pathPrefix setting. That design was wrong: one string for the whole model, but a single codegen run can emit several services that need not share a prefix — which is exactly the multi-service case excludeServices already exists for.

The generated client builds each URL from the operation's @http URI verbatim. That is right when the model describes the whole path, but a service is often mounted under a prefix the model never mentions — a server framework that derives one from a trait, or a reverse proxy — and then every generated request misses it and 404s.

So instead of a setting, an interface:

class InternalPrefix extends TsCodegenExtension {
  override def transformPath(
    service: ServiceShape,
    operation: OperationShape,
    path: List[PathSegment],
  ): List[PathSegment] =
    if (service.hasTrait(classOf[ApiInternalTrait]))
      PathSegment.Literal("internal") :: PathSegment.Literal(service.getVersion) :: path
    else
      path
}

listed in META-INF/services/org.polyvariant.smithy.ts.api.TsCodegenExtension and discovered with ServiceLoader. An extension sees each service and operation, so per-service decisions fall out for free — and a convention the model does carry (a trait, the version field) is something the extension reads rather than something the generator has to know about.

Notes on the design

A path is List[PathSegment], not String. It has two consumers that must tell literals from labels: the client interpolates a label as ${encodeURIComponent(…)}, while the Storybook mock router matches it as a wildcard. A String => String hook would force both to re-parse the result, and would let an extension hand back something that no longer parses at all. Both consumers now resolve through one PathResolver call, so an extension cannot make the client and the mocks disagree about a route.

transformPath, not prefixPath. It replaces the whole path, so an extension can reorder or drop segments too, not only prepend. Nil means /.

What comes back is validated. A Label must name a member bound with @httpLabel, and a Literal may not contain / (which reads as one segment to the client but never matches the mock router's segment-by-segment comparison). Both fail codegen with an error naming the operation, rather than emitting a client that quietly cannot work.

A new smithy-ts-codegen-api module. Same reason traits is separate: an implementor needs smithy-model to inspect shapes, not the generator and its smithy-build/alloy/codegen-core dependencies.

tsCodegenExtensions on the sbt plugin. The forked classpath was closed — resolveCliClasspath(version) and nothing else — so without this the SPI would be unreachable from the recommended entry point. Extension artifacts resolve in the same coursier Fetch as the CLI, so a dependency they share with the codegen (smithy-model, smithy-ts-codegen-api) is reconciled to one version instead of landing on the classpath twice. %% resolves against the codegen's Scala version, not the enclosing project's — nothing on that classpath runs on the latter. The setting is already part of the task's cache key via the resolved jars, so adding or bumping an extension re-runs codegen.

No pathPrefix setting, so there is nothing to deprecate — the plugin, CLI and sbt surfaces are untouched apart from the new setting.

Release note: base version moved to 0.5

generate gains an extensions parameter. The default keeps it source-compatible, but a defaulted parameter still changes the JVM signature, so the two-arg overload disappears — and MiMa catches it against the published 0.4.0:

* static method generate(Model,Set)String in class TsCodegenPlugin
  does not have a correspondent in current version

A bump rather than a ProblemFilters.exclude: generate is the documented programmatic entry point, so the break is genuinely user-visible — unlike the TsWriter filter dropped when 0.4 opened, which covered a class no caller could reach. The reasoning there was that a fresh baseline starts clean and a lingering filter would hide a future break of the same shape; adding one here would do exactly that. Happy to switch to a filter if you would rather keep the next release a patch.

Needs a v0.5.0 tag when it ships — sbt-typelevel checks the release tag against tlBaseVersion.

Verification

• 49 core tests (38 pre-existing + 11 new): per-service dispatch, the operation being visible, reorder/drop, Nil, extensions composing, and both validation failures.
• A new extensions scripted test publishes a real extension artifact and asserts the rewritten path in both the client and the mock segments — the full sbt → forked CLI → ServiceLoader path, including the coursier resolution of %% at the codegen's Scala version. I checked it can actually fail by breaking the expected URL (see tsCodegenSampleCheck can never fail: it regenerates the file it is checking #22 for why that is worth checking here).
• With no extensions the output is unchanged: the committed typecheck/src/generated.ts is byte-identical.
• clean test, scalafmtCheckAll, scalafmtSbtCheck, headerCheckAll, mimaReportBinaryIssues, doc (no warnings), sbtPlugin/scripted (both tests), and nix flake check all green locally.

[kubukoz]

Rebased onto main to pick up #24. One conflict in build.sbt, resolved by keeping both changes — #24 rewrote tsCodegenSampleCheck to generate into a temp file, this branch added api to the root aggregate; they touch adjacent lines but not the same intent.

Re-verified on the rebased tree: 49 tests, scalafmt/headers/mima/workflow+mergify checks, both scripted tests (basic and extensions), and tsCodegenSampleCheck — the last one now via #24's version that can actually fail, and the committed sample still matches.