feat: add lambda-runtime-invocation-id header

[darklight3it]

Summary

Add Lambda-Runtime-Invocation-Id header support for cross-wiring protection.

The RIC now echoes the invocation ID received from RAPID on /next back on /response and /error, enabling RAPID to detect and reject stale responses from timed-out invocations.

Problem

On Lambda Managed Instances (LMI) and On-Demand (OD), when an invoke times out, the runtime process continues running in the background. If a new invoke arrives with the same requestId, RAPID accepts it. The still-running old invocation eventually posts its response, and RAPID matches it to the new invoke — delivering the wrong response (cross-wiring).

Solution

RAPID sends a unique per-invoke nonce via Lambda-Runtime-Invocation-Id header on /next. The runtime echoes it back on /response and /error. RAPID validates the match before accepting the response.

Backward Compatibility

Fully backward compatible in both directions:

• If RAPID doesn't send the header → RIC doesn't see it → doesn't echo → no behavior change
• If RIC doesn't echo it (old version) → RAPID skips validation → no behavior change

Rate-limited malformed-header logging

Added an internal generic RateLimiter for runtime different uses. In this case the request was to rate limit warning caused by malformed Lambda-Runtime-Invocation-Id headers.

The limiter:

• Uses a monotonic Instant and configurable Duration.
• Is protected by a standard mutex because the check-and-update operation must be atomic across concurrent Tokio tasks.
• Is process-local, so a static limiter is shared across warm invocations in the same Lambda execution environment.
• Resets its timestamp and clears mutex poisoning if the mutex is poisoned, since the limiter state is disposable and must not crash the runtime.
• Keeps rate-limiting independent from tracing, allowing a future tracing-subscriber integration without coupling the runtime behavior to a specific subscriber.

Malformed invocation-ID headers are ignored rather than converted with from_utf8_lossy, because the value may be echoed back as an HTTP header and must remain a valid ASCII header value. A rate-limited warning is emitted with the configured interval included as structured log metadata.

Testing

• added unit test
• added a new dockerized test working with the new RIE.

[jlizen]

Core approach is good, but some small tweaks.

Also: currently we log Lambda function timeout! for any 410, but we now will have a 410 if a stale response is rejected. We should tweak the message.