fix: pin owned tracer provider to alwaysOn sampler

[ChoMinGi]

Fixes #12.

What

LangfuseOtel.Builder.build() creates its own SdkTracerProvider without setting a sampler, so it falls back to the SDK default parentBased(alwaysOn) and inherits the sampling decision of whatever span happens to be current. With an OpenTelemetry Java agent or the Micrometer bridge in the same application, LLM spans disappear along with any head-sampled HTTP trace — silently.

This sets Sampler.alwaysOn() explicitly:

tracerProvider = SdkTracerProvider.builder()
        .setResource(resource)
        .setSampler(Sampler.alwaysOn())
        .addSpanProcessor(new LangfuseContextSpanProcessor())
        ...

The provider exports only to Langfuse, so sampling it independently adds no volume to any other backend. No public API changes, no new configuration.

Tests

New ExternalTraceLinkageTest pins down how Langfuse spans behave next to an externally created parent span:

Test	Asserts
langfuseSpansJoinTheSurroundingTrace	same traceId and correct parent chain across the two providers; each exporter sees only its own half
langfuseSpansSurviveAnUpstreamSamplingDrop	LLM spans are exported even when the upstream parent was sampled away — this is the regression guard
builtProviderSamplesIndependentlyOfAnUnsampledParent	exercises the real LangfuseOtel.builder() wiring, not a stand-in
langfuseStartsItsOwnTraceWithoutSurroundingContext	unchanged root-trace behaviour when there is no ambient context

Verified the tests fail on the pre-fix code (builtProviderSamplesIndependentlyOfAnUnsampledParent, 1 failure) and pass with it. Full suite: 193 tests, 0 failures across core and starter.

The builtProvider... test points at an unroutable host and deliberately leaves its span unended — the sampling decision happens at startSpan(), and ending the span would queue a delivery that can only fail slowly. Keeping it out of the export queue holds the class at ~0.25s instead of ~7.4s.

Out of scope

With an agent present the surrounding HTTP/JDBC spans and the LLM spans still land in different backends, so neither holds the complete trace. That needs a duplicate/fan-out exporter and is tracked separately in the notes on #12.