Add runnable examples, each smoke-tested against a stub

[garretpremo]

Refs #20. The issue was closed as not needed, but in-repo examples still help the repo: CI now breaks when an SDK change breaks a realistic program, newcomers have something they can run in one command, and the JS SDK has an examples/ directory too.

What's here

Four examples under examples/. Each is its own Gradle project with a short README, a run task, and a smoke test.

Example	Shows
ticket-triage	Keyed questions, models listing, and API errors; a port of the JS SDK's demo.ts
typed-routing	Ask handles and an enum Choice, routed to a queue by an exhaustive switch
async-batch	systemOneAsync fan-out with per-call options, a custom retry policy, and failures per item
spring-boot	The starter behind POST /tickets/route, with TypeSafe failures mapped to 502/504 ProblemDetail

TYPESAFE_API_KEY=your-key ./gradlew :examples:ticket-triage:run

• Testing: each example takes its client through run(TypeSafeClient), so its test points it at examples/support's in-process StubTypeSafeServer. The Spring test sets typesafe.base-url instead. ./gradlew build checks all four with no API key and no secrets in CI.
• README samples: these are output from real runs against the API.
• Publishing: the root build's shared block now configures only typesafe-sdk and typesafe-sdk-spring-boot-starter, so nothing under examples/ is published. A dry run of publishToMavenCentral touches only those two modules.
• Java level: the examples target Java 17, the same as the SDK.

Follow-ups found while writing these (not in this PR)

• Root README, Spring Boot section: typesafe.api-key=${TYPESAFE_API_KEY} doesn't fail fast when the variable is unset. Boot binds the literal ${TYPESAFE_API_KEY} as the key, so the first request gets a 401. ${TYPESAFE_API_KEY:}, as the starter's Javadoc describes, is the form that works.
• Root README, Async section: an exceptionally callback receives a CompletionException wrapping the TypeSafeException, not the exception itself. Only get()/join() hand back the unwrapped cause.
• Possible API additions: ChoiceAnswer.probability() for the chosen label, and a systemOne(state, RequestOptions, Ask...) overload so per-call options don't force the builder form.

[xbt-a4224j]

I think we want the argmax on the probabilities map to inform the level, rather than the aggregated ScoreAnswer score. Most likely level is the mode vs mean, in other words?

Suggested change

	return "%.2f (%s)".formatted(s.score(), s.legend().get(String.valueOf(Math.round(s.score()))));
	String likeliest = s.probabilities().entrySet().stream().max(Map.Entry.comparingByValue()).orElseThrow().getKey();
	return "%.2f (%s)".formatted(s.score(), s.legend().get(likeliest));

[garretpremo]

Agreed, nice catch. The rounded mean can pick a level that isn't the model's most likely one.

The test fixture shows this: refund_risk has {0: 0.1, 1: 0.4, 2: 0.5}, so the mean is 1.4 and rounds to level 1, though level 2 is the most likely.

AsyncBatch rounded the same way, so I fixed it too and updated the README output.