feat(telemetry): extensible log pipeline + rotating file exporter

[lIang70]

Summary

Introduce an extensible logging pipeline in sdk/telemetry and add a rotating file exporter in sdkx/telemetry/logfile. Together they unblock the long-standing gap of "the server cannot persist its logs to disk", which on macOS effectively means flowcraft logs returns nothing useful (the VM only forwards stdout/stderr that the host never sees).

This PR ships the infrastructure; the wiring change in feat/flowcraft (adding LogConfig.File* fields and pointing the server at a virtio-fs-shared file) is a follow-up.

sdk/telemetry — new public API

API	Role
WithLogProcessor(p sdklog.Processor) LogOption	The canonical OTel pattern: register any number of processors.
ConsoleProcessors(min) []sdklog.Processor	Ready-made stdout/stderr split sink (Exporter + BatchProcessor + SeverityFilter).
NewPlainTextExporter(w io.Writer) sdklog.Exporter	Standard sdklog.Exporter. The previous hand-rolled batching Processor is gone — async batching, queue management and shutdown draining now come from OTel's BatchProcessor.
NewSeverityFilter(base, min, max) sdklog.Processor	Severity gate honouring OTel's Enabled protocol so dropped records are short-circuited before formatting.
FormatPlainTextRecordLine(*sdklog.Record) []byte	Exposed so downstream sinks (sdkx/logfile) can emit the same on-screen format.

sdk/telemetry — deprecations (v0.2.0 removal)

WithLogConsole, WithLogMinSeverity, WithLogExporter are marked Deprecated: with inline migration guides. Behaviour preserved on v0.1.x — calling InitLog() with no options still yields the default console sink.

Migration:

`go
// before
telemetry.InitLog(ctx)

// after
telemetry.InitLog(ctx,
telemetry.WithLogProcessor(telemetry.ConsoleProcessors(otellog.SeverityInfo)...),
)
`

sdkx/telemetry/logfile — new package

go exp, _ := logfile.NewExporter(logfile.Config{ Path: "/var/log/flowcraft/server.log", MaxSizeMB: 100, MaxBackups: 7, MaxAgeDays: 30, }) telemetry.InitLog(ctx, telemetry.WithLogProcessor(sdklog.NewBatchProcessor(exp)), )

Lives in sdkx because lumberjack would otherwise be an unwanted transitive dependency for sdk core consumers.

Compatibility & rollout

• ✅ All existing call sites (sdk tests, plugin, examples) continue to compile and behave identically — deprecation is annotation-only.
• ✅ No version drift on the OTel stack:
  • sdk: pulls go.opentelemetry.io/otel/sdk/log/logtest@v0.16.0 as a direct test dep, everything else stays on v1.40 / v0.16.
  • sdkx: pulls sdk/log v0.16.0 + sdk/log/logtest v0.16.0 + lumberjack.v2 v2.2.1, everything else stays on v1.40 / v0.16.
• The auto-tag workflow will tag sdk first, then open a chore/bump-sdkx-sdk-vX.Y.Z PR. After that PR is merged, sdkx gets tagged with the new logfile package.

Test plan

• cd sdk && go test -count=1 ./... — full suite green
• cd sdkx && go test -count=1 ./... — full suite green (logfile package included)
• cd plugin && go build ./... && go vet ./... — green
• cd examples/voice-pipeline && go build ./... && go vet ./... — green
• gofmt -l ./... clean
• New TestInitLog_ForwardCompatible_ConsoleViaProcessor exercises the recommended migration path end-to-end.
• New TestPlainTextExporter_Export_WrappedInBatchProcessor validates the Exporter+BatchProcessor composition that ConsoleProcessors actually produces.

Made with Cursor