Server-side request forgery in signalk-server app store icons

### Summary The app store icon code (`dist/appstore/icon-probe.js` around line 200 and `icon-bytes.js` around line 138) resolves a plugin's declared `signalk.appIcon`. Relative paths are pinned to the CDN, but an absolute http(s) URL is used as-is: the server fetches it, follows redirects, and stores any `image/*` response as the plugin's icon, which is then served to the admin UI. Unrelated to GHSA-q59x-jc9f-gfqf. ### Affected signalk-server 2.33.0 (latest). ### Reproduction The real dist modules driven directly, Docker with `--network none`; a local "internal" service on 127.0.0.1 logs requests: ``` [CONTROL relative] declared=../../icon.png resolved=null internal-service hits: [] stored: null [ATTACK absolute] declared=http://127.0.0.1:35013/latest/meta-data/iam resolved=http://127.0.0.1:35013/latest/meta-data/iam internal-service hits: ["GET /latest/meta-data/iam"] stored: .../icon-bytes/[email protected] (70 bytes) [ATTACK redirect] declared=http://127.0.0.1:35013/redir internal-service hits: ["GET /redir","GET /internal-secret-via-redirect.png"] stored: .../icon-bytes/[email protected] (70 bytes) ``` The modules were tested directly rather than through a full running server. ### Impact Anyone who can get a plugin listed in the app store (publishing an npm package with the signalk keywords) can make every signalk-server that browses the app store send requests to internal addresses on the vessel network and to cloud metadata endpoints. Responses with an image content type are stored and served back to the user. ### Suggested fix Only accept relative icon paths resolved against the CDN (or an https allowlist of known hosts), do not follow redirects to other hosts, and reject private, loopback and link-local addresses after resolution.