Set the request ID before the trace layer reads it

[shaurya703]

Fixes #790. Also makes the README claim in #813 true, so that one can be closed or re-checked after this lands.

The fix

SetRequestIdLayer now comes after trace_layer in the chain, which is what makes it run first. Chained Router::layer() calls make the last one added the outermost, so the request reached them bottom-up and make_span_with was reading an extension that had not been written yet.

I left a comment above the chain spelling the direction out, because reading it the natural way is exactly how this happened.

Why the existing test could not catch it

test_request_id_and_completion_logs asserts the response header, and the header never broke: PropagateRequestIdLayer only needs the id by the time the response is built. So the feature was dead in the logs while its test stayed green — which is the part worth fixing properly, not just the ordering.

The new test captures the span's own request_id field through a subscriber and asserts it is non-empty and equal to the header.

Verified against the old order:

every span carried an empty request_id — the trace layer ran before SetRequestIdLayer
ORIGINAL order -> 3 passed; 1 failed
FIXED order    -> 4 passed; 0 failed

The other three passing under the broken order is the whole point.

Two implementation notes

• It reads the field, not formatted output, so it does not depend on the log format staying JSON.
• The value arrives via record_debug, not record_str: the span uses request_id = %request_id, a Display value. My first version implemented only record_str and captured nothing — the test failed with "no request span was recorded at all", which is a false negative dressed as a failure. Both are implemented now so it cannot quietly stop seeing the field.

There is also a floor assertion that at least one span was recorded, so an empty capture cannot pass for a check.

Checks

cargo test — 16 suites green. cargo fmt --check and cargo clippy --all-targets -- -D warnings clean.