refactor(drainer): removed fred dependency from drainer - #171

… collections facade

TEMPORARY PIN. The nine deja revisions move from main `8d87c19` to `159aadc`,
the head of deja's `work/teardown-safe-correlation-reader` (PR #171). Every
manifest says so, because a bare revision looks exactly like a released one.
This must be bumped back to a main commit once #171 merges, and that bump is a
precondition for review rather than a follow-up to it.

A revision rather than `branch = "..."`. A branch pin re-resolves on any lock
refresh, so the deja underneath would move without a manifest edit — and deja
records its own sha into every tape it writes, which makes a moving pin a moving
experiment. The branch name rides in the comment, where it informs without
deciding what gets built.

WHY IT CANNOT WAIT FOR THE MERGE. `common_utils::collections` gives
`HashMap`/`HashSet` a correlation-derived hash seed, so a set's iteration order
is the same in a replay as in the recording. It does not compile against deja
main at all: `Default for CorrelationHasher` runs on every `HashMap::new()`,
destructors included, and `current_correlation_id` reads its thread-local with a
plain `with`/`borrow`, which ABORTS the process there rather than failing a
request. #171 adds the fallible twin the facade calls. Pinning the branch is what
lets this be built and replayed now instead of after two merges.

WHAT IT DOES NOT DO. Nothing calls the facade. It is the mechanism, not the
adoption — the constructors exist and no collection uses them yet. The target is
`payment_methods_enabled`, built at
`crates/router/src/core/payment_methods/cards.rs:5215` by iterating nested
HashMaps into Vecs; ordering there is 26 of 27 blocking body mismatches on the
run we care about. That construction path is verified. The causal link to those
26 is strongly indicated and NOT proven against a failing scorecard, which is
exactly what a build carrying this is for.

CHECKED. `common_utils` at --features deja and `router` at
--features v1,deja,release, both clean. The common_utils green was verified
capable of failing first: the seeded hasher sits behind
`#[cfg(feature = "deja")]`, so a run without it compiles none of the file and
reports success anyway. A `compile_error!` inside `Default for
CorrelationHasher` fired under this feature set.

… collections facade

TEMPORARY PIN. The nine deja revisions move from main `8d87c19` to `159aadc`,
the head of deja's `work/teardown-safe-correlation-reader` (PR #171). Every
manifest says so, because a bare revision looks exactly like a released one.
This must be bumped back to a main commit once #171 merges, and that bump is a
precondition for review rather than a follow-up to it.

A revision rather than `branch = "..."`. A branch pin re-resolves on any lock
refresh, so the deja underneath would move without a manifest edit — and deja
records its own sha into every tape it writes, which makes a moving pin a moving
experiment. The branch name rides in the comment, where it informs without
deciding what gets built.

WHY IT CANNOT WAIT FOR THE MERGE. `common_utils::collections` gives
`HashMap`/`HashSet` a correlation-derived hash seed, so a set's iteration order
is the same in a replay as in the recording. It does not compile against deja
main at all: `Default for CorrelationHasher` runs on every `HashMap::new()`,
destructors included, and `current_correlation_id` reads its thread-local with a
plain `with`/`borrow`, which ABORTS the process there rather than failing a
request. #171 adds the fallible twin the facade calls. Pinning the branch is what
lets this be built and replayed now instead of after two merges.

WHAT IT DOES NOT DO. Nothing calls the facade. It is the mechanism, not the
adoption — the constructors exist and no collection uses them yet. The target is
`payment_methods_enabled`, built at
`crates/router/src/core/payment_methods/cards.rs:5215` by iterating nested
HashMaps into Vecs; ordering there is 26 of 27 blocking body mismatches on the
run we care about. That construction path is verified. The causal link to those
26 is strongly indicated and NOT proven against a failing scorecard, which is
exactly what a build carrying this is for.

CHECKED. `common_utils` at --features deja and `router` at
--features v1,deja,release, both clean. The common_utils green was verified
capable of failing first: the seeded hasher sits behind
`#[cfg(feature = "deja")]`, so a run without it compiles none of the file and
reports success anyway. A `compile_error!` inside `Default for
CorrelationHasher` fired under this feature set.

TEMPORARY PIN. The nine deja revisions move from main `8d87c19` to `159aadc`,
the head of deja's `work/teardown-safe-correlation-reader` (PR #171). Every
manifest says so, because a bare revision looks exactly like a released one.
This must be bumped back to a main commit once #171 merges, and that bump is a
precondition for review rather than a follow-up to it.

A revision rather than `branch = "..."`. A branch pin re-resolves on any lock
refresh, so the deja underneath would move without a manifest edit — and deja
records its own sha into every tape it writes, which makes a moving pin a moving
experiment. The branch name rides in the comment, where it informs without
deciding what gets built.

WHY. #171 adds `try_current_correlation_id`, the fallible twin of
`current_correlation_id`. The collections facade, raised as its own change on
top of this one, calls it from `Default for CorrelationHasher`, which runs on
every `HashMap::new()`, destructors included; the plain reader reads its
thread-local with `with`/`borrow` and aborts the process there rather than
failing a request.