Fix source.dot.net proxied-index serving (500, .js, references, SolutionExplorer)

[tannergooding]

Several defects that break source.dot.net, all rooted in the same thing: it serves the index from Azure blob storage through the proxy layer (SOURCE_BROWSER_INDEX_PROXY_URL set), where sites that serve the index from local disk (e.g. source.terrafx.dev, proxy disabled) never exercise the affected paths. That's why #264 surfaced them only on source.dot.net.

---

SolutionExplorer.html -> HTTP 500

Helpers.ProxyRequestAsync called Convert.ToBase64String(props.ContentHash) unconditionally. Azure does not guarantee a blob has a Content-MD5: block-uploaded blobs (the larger files, e.g. the ~2.8 MB SolutionExplorer.html) lack one, whereas smaller single-PutBlob uploads carry it. Convert.ToBase64String(null) threw, was rethrown as InvalidOperationException, and produced an empty-body 500. Every smaller proxied file returned 200 (with a Content-Md5), so only the large files broke.

Fix: only append Content-Md5 when ContentHash is present.

---

Symbol navigation shows "Don't use this page directly, pass #symbolId to get redirected."

#264 introduced a two-level symbol redirect where each A.html loads a generated per-assembly A.files.js. The proxy only served .html/.txt, so on a proxied deployment the .js fell through to the static-file provider -- which does not have the index on local disk -- and 404'd, leaving the redirect stub. Confirmed live: .../a.html -> 200 (blob), .../A.files.js -> 404.

Fix: also proxy that file, using the same FileExists fall-through. Scoped to the .files.js suffix -- the only .js the generator emits into the index -- so chrome scripts (scripts.js) keep serving from wwwroot rather than being proxied.

---

Reference fragments (/{assembly}/R/{id}.html) -> 404

The per-symbol reference fragments are packed into a single references.pack (+ references.index) served by ReferencePackMiddleware, which read them via raw File.* -- local disk only. On the proxied deployment the pack is uploaded to blob rather than shipped with the webapp, so every reference fragment 404'd. Confirmed live: a real source page linking R/36a0ef01cb5d5107.html etc., all 404.

Fix: make ReferencePack blob-aware, mirroring how IndexLoader already falls back to AzureBlobFileSystem. The small references.index is read into memory once; each fragment is then streamed straight to the response -- a ranged blob GET, or pooled chunked reads locally -- via a new IFileSystem.CopyBytesToAsync. Streaming rather than buffering means a heavily-referenced symbol's (multi-MB) fragment doesn't force a large-object-heap allocation per request. The local file-handle path is otherwise unchanged.

---

Graceful SolutionExplorer.html fallback

The nav frame redirects to /SolutionExplorer.html; the pipeline serves the generated one from the index (blob or local) and only falls through to wwwroot when it's absent. Added a static placeholder there -- matching the generated page's chrome, but with no tree and no onSolutionExplorerLoad() -- so an index without one shows a "use search" note in the nav pane instead of a 404.

---

Verified SourceIndexServer builds clean and the fallback is included on publish. The blob paths can only be fully exercised against the live proxied deployment (private container), so a post-deploy check is warranted. This is the vendored SourceBrowser copy; the same fixes should also land upstream in tannergooding/SourceBrowser on the next re-vendor.