test/ci: restore code coverage (regressed ~96% → ~87% after 0.8.0 consolidation)

[JustinKovacich]

Summary

Project code coverage regressed from ~96% to ~87% after the 0.8.0 consolidation landed on main (#138 — the forward-port stack + the entire 0.8.0 spine, phases 18–22). This is not blocking CI: the codecov gate (codecov.yml) is project/patch target 80%, and 87% clears it. But it's a ~9-point quality regression worth recovering.

Why coverage dropped

The consolidation merged a large amount of new alloc-lane code whose host-test coverage is thinner than the pre-0.8.0 baseline, diluting the project percentage. Coverage is measured only on the alloc/host feature set (ci.yml):

cargo llvm-cov nextest --no-default-features --features $ALLOC_FEATURES --lcov ...

So two distinct gaps compound:

1. New alloc-lane code with thin host tests — likely contributors (large, recently added/reworked, exercised by relatively few host tests):

   • src/server/event_publisher.rs (~1530 LoC) — publish_raw_event_to / publish_raw_event_to_with_buffers / subscriber_addresses (feat(server): forward-port publish_raw_event_to + subscriber_addresses onto 0.8.0 #135 forward-port)
   • src/client/socket_manager.rs (~1640 LoC) — dual-socket per-transport SD (fix(client): per-transport SD session tracking via dual discovery sockets (+ Windows CI) #130 forward-port)
   • src/e2e/registry.rs — per-source RX E2E state (feat: forward-port per-source RX demux (v0.7.3) onto 0.8.0 #137 forward-port)
   • src/buffer_pool.rs, the StaticE2EHandle / StaticSubscriptionHandle / SharedHandle machinery, and the phase-20/22 server alloc-elimination refactors
   • error/Err(_) branches and capacity-saturation paths (heapless FnvIndexMap full, SUBSCRIBERS_PER_GROUP overflow, oversize-datagram drops) that aren't hit by happy-path tests

2. Unmeasured code paths — #[cfg(not(feature = "_alloc"))] no-alloc branches and the bare-metal-runtime module are not in the $ALLOC_FEATURES build at all, so they neither help nor hurt the percentage today. They are genuinely untested-by-host-coverage but are partially exercised by no_alloc_witness / bare_metal_e2e / the thumbv7em + build-std lanes (which don't feed codecov).

Suggested approach

1. Pull the codecov file-level report for the feat: consolidated 0.8.0 stack (forward-ports + #130) → main #138 merge (or run cargo llvm-cov nextest --no-default-features --features $ALLOC_FEATURES --html locally) and sort by lowest coverage to find the actual worst offenders — confirm the list above rather than assuming.
2. Add targeted unit/integration tests for the highest-LoC, lowest-coverage files first (biggest percentage recovery per test). Prioritize error and capacity-bound branches, which are cheap to cover and currently skipped.
3. Decide whether the no-alloc / bare-metal paths should contribute to a coverage signal at all (separate codecov flag for the bare_metal lane?), or stay covered only by the no_alloc_witness / bare_metal_e2e gates. Track that decision here.

Acceptance criteria

• Identify the lowest-covered files from the codecov report (attach the breakdown).
• Restore project coverage to ≥ 96% (back to the pre-0.8.0 baseline).
• No new #[allow]/grcov: ignore-style exclusions used to inflate the number — real tests only.
• After coverage is recovered, raise the codecov.yml project/patch target from 80% to ~95% so the level holds. ⚠️ Do not raise the gate before recovery — at the current 87% a 96% target would turn the coverage check red on every PR and block all merges.

Context

• Regression introduced by: feat: consolidated 0.8.0 stack (forward-ports + #130) → main #138 (consolidated 0.8.0 stack → main).
• Coverage config: codecov.yml (target 80%), coverage job Build, Test & Coverage in .github/workflows/ci.yml.