[v3,DX] use exponential backoff when waiting for frontend dev server to start

[Liumingxun]

Is your feature request related to a problem?

When running wails dev with a frontend dev server (e.g. Vite, webpack, etc.) that takes more than ~5 seconds to boot, the app is killed with a fatal error before the server ever becomes reachable:

[vite] connected.
11:23PM INF Retrying...
11:23PM INF Retrying...
11:23PM INF Retrying...
23:23:36 [types] Generated 1ms
 astro  v6.3.7 ready in 3525 ms
┃ Local    http://localhost:9245/
┃ Network  use --host to expose
23:23:36 watching for file changes...
23:23:36 [vite] ✨ optimized dependencies changed. reloading
11:23PM ERR 

******************************** FATAL *********************************
*      There has been a catastrophic failure in your application.      *
**************************** Error Details *****************************
unable to connect to frontend server. Please check it is running - FRONTEND_DEVSERVER_URL='http://localhost:9245'************************************************************************

The current implementation in v3/pkg/application/application_dev.go (preRun) retries 10 times with a fixed 500 ms sleep between each attempt. That gives a maximum total wait window of 5 seconds — which is too short for many real-world setups (first-run installs, cold TypeScript compilation, large monorepos, CI machines, etc.).

The dev server is often just about to start when the timeout fires, turning what should be a 6–8 second startup into an immediate hard failure.

Describe the solution you'd like

Replace the fixed 500 ms sleep with exponential backoff:

• Base delay: 250 ms (so fast servers connect almost instantly)
• Multiplier: 2× per failed attempt
• Per-attempt cap: 5 s
• Retries: 10 (unchanged)

This yields a total retry window of roughly 32.75 s, which comfortably covers slow-starting servers while not regressing the happy path — a fast server still connects on the first attempt with near-zero overhead.

The change also improves retry logging to include attempt number and next_delay, making it easier to diagnose startup problems.

Describe alternatives you've considered

• Increase the fixed sleep (e.g. to 2 s): extends the happy-path wait unnecessarily.
• Make the timeout configurable: valid but adds API surface; exponential backoff solves the common case without any new config.
• Configurable total timeout: could be a follow-up enhancement on top of this.

Additional context

Affected file: v3/pkg/application/application_dev.go — preRun().

I have a working implementation ready and will open a PR referencing this issue.