Fix: HTTP raw stream resolution reliability (timeouts + optimistic fallback)

[Walkoud]

Summary

This PR improves NodeLink HTTP source reliability for raw radio streams (for example http://.../stream) that may not answer consistently to HEAD or may exceed worker timeout budgets.

The goal is to prevent loadtracks failures/timeouts and return a playable track whenever possible.

Problem

• Some HTTP radio links resolve successfully with Lavalink but intermittently fail in NodeLink.
• loadtracks could fail when probe requests (HEAD then fallback GET) consumed too much time.
• In failure paths, NodeLink could return exceptions instead of a usable stream track.

Changes

1) HTTP source timeout budgeting and safer probing

File: src/sources/http.js

• Added configurable timeout behavior via sources.http:
  • resolveTimeoutMs (default 7000)
  • headTimeoutMs (default 2500)
  • optimisticOnProbeFailure (default true)
• Added cluster-aware timeout budgeting:
  • Resolve budget is capped against cluster.commandTimeout (with safety margin).
  • Fallback GET probe uses remaining timeout budget only.
• Added Icy-MetaData: 1 on fallback probe to better handle radio/ICY endpoints.
• Added optimistic fallback track creation on probe failures, HTTP errors, or resolve exceptions (when enabled).

2) Hard timeout enforcement for low-level HTTP requests

File: src/utils.js

• Added hard timeout guard around Node HTTP requests to ensure requests do not stay pending beyond configured timeout.
• Added single-settle guards (resolveOnce / rejectOnce) for safer promise completion in request/error/timeout races.
• Preserved existing retry behavior and redirect handling.

Why this works

• The HTTP source now avoids spending unbounded time in probe steps.
• Worker commands are less likely to exceed timeout windows.
• When upstream behavior is imperfect (slow/no HEAD/unstable metadata), NodeLink can still return a stream track and proceed to playback.

Validation

Syntax checks

• node --check src/sources/http.js
• node --check src/utils.js

Runtime verification

• Started NodeLink and tested:
  • GET /v4/loadtracks?identifier=http://144.24.202.161:25509/stream
• Result:
  • loadType: "track" returned successfully
  • Encoded track and sourceName: "http" present

Backward compatibility

• Default behavior stays safe and compatible.
• New options are optional and only refine timeout/fallback behavior.

Notes

• This PR intentionally focuses on reliability for raw HTTP streams.
• Logging verbosity is controlled by NodeLink config (logging.level and logging.debug.*), not by this PR.

Checklist

• Reproduced issue context with raw HTTP links
• Implemented source-level timeout budget and fallback strategy
• Implemented low-level hard timeout guard
• Verified syntax and runtime loadtracks behavior