The direction here is right and the extraction of binding_matches into a single BindingMatchRule::matches (eliminating the dual matcher) is clean and behavior-equivalent — I verified that field-by-field and the inbound path is unchanged. But resolve_channel_owner relies on a premise that doesn't hold on boot-from-config, and it can re-open the cross-agent leak this PR is meant to close (#6022 / #4824).

The kernel mesh binding store is not specificity-sorted on boot.
resolve_channel_owner takes the first match (bindings.iter().find(...)), commenting that the Vec is kept specificity-sorted. But:

• self.mesh.bindings is a Mutex<Vec<AgentBinding>> stored as-is by MeshSubsystem::new (subsystems/mesh.rs:73), populated from config.bindings in config file order (boot.rs:1263, 1523).
• Only the runtime add_binding path sorts (bindings_and_handle.rs:196). A plain config-boot store is unsorted.
• The inbound router uses a separate store that is sorted (librefang-channels/src/router.rs:152 load_bindings), so inbound is most-specific-first but the outbound mirror reads the unsorted kernel store.

So when two bindings both match the same (channel, chat_id) — e.g. a broad channel-only binding (agent D) plus a specific peer_id binding (agent B) — and the broad one is written first in config, the mirror resolves to D while the inbound reply still routes to B. Outbound context lands on the wrong agent: the same failure mode as #6022, with the trigger changed from "default_agent" to "binding declaration order".

The tests don't catch this because they inject via kernel.add_binding(...) (which sorts) and use a single binding — they never exercise the unsorted config-boot path or a multi-match contest.

Suggested fix (option A, minimal): don't depend on store order — select the highest-specificity match explicitly:

bindings
    .iter()
    .filter(|b| b.match_rule.matches(channel, None, chat_id, None, &[]))
    .max_by_key(|b| b.match_rule.specificity())
    .map(|b| b.agent.clone())

(Alternatively, option B: sort the Vec inside MeshSubsystem::new so the kernel store shares the inbound router's invariant — broader blast radius, so please add a store-ordering assertion test if you go that way.)

Add two regression tests for the currently-uncovered paths:

1. Boot-from-config: start from KernelConfig { bindings: vec![...], .. } directly (not add_binding) and assert the mirror owner is correct — this is the unsorted path.
2. Multi-match contest: put two matching bindings on the same (channel, chat_id) — a broad channel-only one and a specific peer_id one — with the broad one first in config, and assert the owner resolves to the specific peer_id agent. With the current find-based code this test fails; that's the regression it should pin.

The fallback-to-default_agent path, the BindingMatchRule::matches extraction, and the out-of-scope follow-up you flagged (direct_route / user_default layers) all look fine — just the binding-layer ordering needs to not rely on the unsorted store.

Good catch — the premise is real and verified: MeshSubsystem::new (subsystems/mesh.rs:73) stores config.bindings as-is in file order, only add_binding (bindings_and_handle.rs:197) sorts, and the inbound router keeps a separately-sorted copy (router.rs::load_bindings). So resolve_channel_owner's find-first read of the unsorted kernel store could mirror outbound context to a broad binding declared earlier in config while the inbound reply routed to a more-specific one — the same split as #6022, retriggered by declaration order. The comment claiming the Vec is "kept specificity-sorted on load" was wrong for the config-boot path.

Fixed in b127308 (option A — select max specificity explicitly, no dependence on store order):

let mut best: Option<&AgentBinding> = None;
for b in bindings.iter().filter(|b| b.match_rule.matches(channel, None, chat_id, None, &[])) {
    if best.is_none_or(|cur| b.match_rule.specificity() > cur.match_rule.specificity()) {
        best = Some(b);
    }
}
best.map(|b| b.agent.clone())

One refinement over the max_by_key snippet: max_by_key returns the last element on a specificity tie, whereas the inbound router does a stable descending sort and takes the first match. To keep the two paths from drifting on equal-specificity bindings, the fold replaces only on strictly-greater specificity, so the first equal-specificity match wins — matching inbound exactly.

Added both regression tests you asked for (crates/librefang-kernel/src/kernel/tests.rs):

1. resolve_channel_owner_uses_unsorted_config_boot_bindings — boots from KernelConfig { bindings: vec![..] } directly (not add_binding), exercising the unsorted store.
2. resolve_channel_owner_prefers_specific_binding_over_broad_in_config_order — broad channel-only binding declared first, specific peer_id binding second; asserts the specific agent wins. Fails against the old find-based code.

cargo check -p librefang-kernel --lib, clippy -p librefang-kernel --lib -- -D warnings, and the three resolve_channel_owner_* tests all pass locally.