fix(core): preserve background start failures

[LiuLin1220]

Summary

• publish an explicit stopped status when a background Core start RPC fails
• preserve the gRPC status name and message instead of replacing every failure with failed to start background core
• classify an unavailable Core as backgroundCoreNotAvailable while retaining unexpected Core errors verbatim

The change is limited to App-side error propagation and connection state recovery. It does not change Core configuration generation, retry behavior, platform permissions, or service setup.

Why

Different Core startup failures currently collapse into the same dialog, even though the original GrpcError contains the actionable cause. The catch path also returns before explicitly publishing a stopped status.

During Windows integration testing, the hidden error was:

start service: start dns/tcp[dns-remote-no-warp]: detour to an empty direct outbound makes no sense

That Core configuration bug is addressed separately by hiddify/hiddify-core#146. Existing reports such as #2276, #2290, and #2291 demonstrate that the same generic App message also hides unrelated permission and platform failures; this PR improves their diagnostics but does not claim to fix each underlying cause.

Testing

• flutter test --no-pub test/hiddifycore/core_start_failure_test.dart (3 tests)
• flutter test --no-pub (28 tests on this standalone branch)
• flutter analyze --no-pub (reports the repository baseline plus the existing flutter_test dependency info for the new test; no new production error)
• Combined fork Windows build and runtime validation: https://github.com/LiuLin1220/hiddify-app/actions/runs/32567872572

The combined Windows artifact also passed a real generated-config startup smoke test and an HTTP 204 request through the resulting local proxy.