[e2e] Retry the endpoint probe when the tunnel is not up yet

ResolveProxyIP exists to wake the lazy proxy peer, and it retried only
curl exit 6 — DNS. The wake-up attempt that arrives before WireGuard has
brought the tunnel up fails with exit 7 instead, and that returned
immediately:

  no HTTP response from vast-azalea.netbird.local: exit status 7
  (curl: (7) Failed to connect ... after 0 ms)

So the one function whose job is to tolerate a not-yet-ready endpoint
failed on the readiness state it was written for, one second after the
client container reported ready. Retry both exit codes within the same
window; anything else would still be failing when the window closed and
still fails immediately.

Raise the access-log ingest window to 60s for the same reason. The proxy
streams each entry with a 10s send timeout of its own, so 30s left
barely three attempts of headroom before a test that had already got its
200 was failed for a row still in flight.

e2e/agentnetwork/custom_pricing_test.go

@@ -174,7 +174,12 @@ func chatOnce(t *testing.T, ctx context.Context, env pricedEnv, model, sessionID
 
 // accessLogIngestWindow is how long a single request's access-log row is given
 // to appear before the caller gives up on it.
-const accessLogIngestWindow = 30 * time.Second
+// accessLogIngestWindow bounds how long a row may take to appear after its
+// request returned. The proxy streams each entry to management with a 10s send
+// timeout of its own, so a request whose send hits one full timeout and is
+// retried has not yet missed anything real — 30s left barely three send
+// attempts of headroom and lost the race on a loaded runner.
+const accessLogIngestWindow = 60 * time.Second
 
 // accessLogPollInterval is how long the lookup waits between pages. Ingest is
 // asynchronous, so the row lands somewhere inside the window rather than on