docs: include widget notification audio in restricted-instance asset guidance

Open the restricted-instance guide and read the widget-assets section referenced in the issue. Update the four-path wording to include /audio/widget/ding.mp3, explain that it must be reachable without an authentication redirect with audio content type and CORS headers preserved, and distinguish login redirects from browser autoplay restrictions. Done means the guidance covers the exact-file exception and troubleshooting case without suggesting broader asset exposure.

The restricted-instance guide lists four widget asset paths but omits the notification sound, /audio/widget/ding.mp3.

With Chatwoot v4.17.0 behind an authentication gateway, the widget loaded normally but Firefox could not download its sound. The gateway returned a 302 login redirect instead of the MP3, producing a CORS error. Being signed in to the embedding application did not solve this.

The audio helper uses fetch(new Request(resourceUrl)), whose default credentials mode does not send cross-origin gateway cookies. The CORS initializer already permits /audio/* GET/OPTIONS from any origin.

Suggested documentation improvement:

• Include the default widget sound /audio/widget/ding.mp3 in the asset guidance and update the four-path wording.
• Explain that this static sound must be reachable without an authentication redirect, with its audio content type and CORS response headers preserved. An exact-file exception is sufficient for the default widget tone; exposing arbitrary audio or help-content paths is unnecessary.
• Add a troubleshooting distinction: a sound request redirected to login is a gateway/network failure; browser autoplay restrictions can still apply after a successful download.

Verified on our deployment after adding that exact-file exception: a cookie-free cross-origin request returned 200 audio/mpeg, Access-Control-Allow-Origin: *, 2,667 bytes, with no redirect. Firefox successfully decoded it through AudioContext.decodeAudioData. Neighboring audio paths and protected help content continued to require authentication. No Chatwoot code change or additional origin CORS configuration was needed.