fix(appnet): tryDirectPingDial shortcut bypassed MinHops constraint

[0pcom]

Summary

Follow-up to #2749. Independently diagnosed by Gamma at 23:12Z post-merge of #2749 with same root cause and same proposed fix; I had already committed mine locally — first one to push wins, they can close their duplicate.

#2749 plumbed `MinHops` through `visor.PingConfig` → `rpcgrpc.PingConf` → `appnet.PingContextWithMinHops` → `router.DialOptions.MinHops`, and `router.DialRoutes` correctly suppresses its direct-transport fast-path downgrade when `opts.MinHops > 1`. But there's an earlier shortcut at `pkg/app/appnet/skywire_networker.go:376` (PingContextWithOpts) that bypasses `router.DialRoutes` entirely:

```go
if directConn, ok := r.tryDirectPingDial(addr, opts); ok {
return &SkywireConn{
Conn: directConn,
freePort: freePort,
}, nil // <-- nrg=nil, RouteHopDetails() empty
}
conn, err := r.r.PingRoute(ctx, pk, ..., opts)
```

`tryDirectPingDial` dials via `appDirectMux` directly, returning a `SkywireConn` with no `NoiseRouteGroup` attached. Consequences:

1. Even with `opts.MinHops >= 2`, when the destination has a direct transport reachable via `appDirectMux`, the dial succeeds via the shortcut and MinHops is silently defeated.
2. The returned `SkywireConn` has `nrg=nil`, so `RouteHopDetails()` returns nil — visible as the `hops_count=0` Gamma reported in both `MuxRouteEstablished` and the post-fix(visor/router): plumb mux-bw --min-hops through DialPing → router #2749 N=8 run.

Gamma's empirical confirmation:

• N=1 `--min-hops 2`: 282ms setup, hops_count=0
• N=1 no min-hops: 466ms setup, hops_count=0
• N=8 `--min-hops 2`: ~100ms each, hops_count=0

Setup times that fast on supposed multi-hop routes are also a tell — actual multi-hop setup is 1-10s.

Fix

```go
if opts.MinHops <= 1 {
if directConn, ok := r.tryDirectPingDial(addr, opts); ok {
return &SkywireConn{...}, nil
}
}
// Falls through to r.r.PingRoute, which returns a real nrg.
```

No proto change, no new API, no behavior change for callers that don't set MinHops.

Effect post-merge

`mux-bw --routes N --min-hops 2` actually routes through intermediates end-to-end:

• `tryDirectPingDial` skipped
• `r.r.PingRoute` → `router.DialRoutes` with `opts.MinHops=2`
• returned conn is a `*router.NoiseRouteGroup` wrapped in `SkywireConn{nrg: ...}`
• `SetForwardHops` was called by `router_dial.go:186` after route setup; `nrg.forwardHops` is populated
• `SkywireConn.RouteHopDetails()` returns the hops
• `visor.GetPingRouteDetailsAt(ref)` returns the hops
• `MuxRouteEstablished.hops` is populated, `hops_count > 0`

Gamma's hops_count=0 observation should disappear, and the operator's hypothesis test can finally use the actual chosen intermediates to verify route diversity from the wire.

This also invalidates the 1.78x throughput claim from Gamma's 23:05Z run — those routes were still going direct via tryDirectPingDial. The Beta↔Gamma ~1.30 Mbps ceiling we both observed is more likely a NIC/upstream cap of a single direct stcpr, not the bandwidth-via-intermediates result we thought.

Test plan

• `go build ./...` clean
• `golangci-lint run` clean (0 issues)
• Live: `mux-bw --routes 1 --min-hops 2 ` → setup time >1s, `hops_count > 0` in `route_established` event
• Live: `mux-bw --routes 8 --min-hops 2 ` → 8 routes with distinct hop paths visible in the per-route summary