feat(collector): log extension startup completion and duration

[mvanhorn]

Summary

The collector extension emits a "Launching OpenTelemetry Lambda extension" info log at process start, but nothing marks that startup has finished or how long it took. This adds a single info-level "OpenTelemetry Lambda extension startup complete" log carrying a startup_duration field, emitted once the collector has started successfully.

A start timestamp is captured in main.go immediately before the launch log and threaded into lifecycle.NewManager (the only production caller, so the signature change is contained). After collector.Start returns successfully in manager.Run, the completion log is emitted with zap.Duration("startup_duration", time.Since(startTime)). The duration measures from the extension's launch log through successful collector start.

Why this matters

Operators consuming the info-level firehose currently cannot tell when the extension is actually ready, nor measure its contribution to cold start. In #2101, @wpessers confirmed this is a valid concern, split the original report into two sub-features, and narrowed the remaining ask to exactly this startup-duration logging. This keeps it a single info-level statement so it is visible in the default firehose, with no new log-level knob (the log-decoupling sub-feature is out of scope and already addressed separately).

Testing

Added TestRunLogsStartupDuration in manager_test.go using a zap observer core:

• Happy path: a successful MockCollector start emits exactly one startup-complete log with a non-negative startup_duration field.
• Edge case: a zero-value start time still produces a valid (non-negative) duration and does not panic.
• Error path: when collector.Start returns an error, the startup-complete log is NOT emitted and Run returns the error, preserving current failure behavior.

go build ./..., go vet, and go test ./internal/lifecycle/... pass in the collector module.

Fixes #2101

[wpessers]

Thanks @mvanhorn for working on this! I'm a bit swamped at the moment but will take a look as soon as possible!

[wpessers]

I know this is an existing test you didn't touch but since your addition of the extension startup log line, it has become flaky. I've noticed it panicking several times when I was running the tests locally. Looks like it's because the last case in here runs lm.Run(ctx) inside a goroutine that is never joined, using the logger which is zaptest.NewLogger(t), and thus it panics when anything logs after the test returns.

I think the goroutine needs to be joined before this test returns, and maybe switch require.NoError to assert.NoError for safety also.

[wpessers]

The log line in itself is correct, but an existing test has become flaky due to its addition. See comment in the testfile.