Fix Linux OOM: disable Blossom SHA-256 URL auto-detection

Commit 214c42b (v0.12.6) added auto-detection of content-addressed
Blossom URLs (64-hex SHA-256 paths) as <img> elements. Blossom is
widespread in modern Nostr feeds — every feed page started rendering
3-5x more <img> elements. Combined with WebKitGTK's weak decoded-
bitmap eviction, feed scrolling grew the WebKit web process to
8-12 GB and triggered WebKit's self-kill threshold with:

  Unable to shrink memory footprint of process (9022 MB) below
  the kill threshold (8192 MB). Killed

Disable BLOSSOM_URL_REGEX in parseContent(). Real Blossom images
shared via standard upload flows (with proper extensions) still
render. Proper reintroduction (HEAD request + Content-Type
validation, or known-server whitelist) planned for v0.12.9.

Also restore feed depth caps to pre-crisis values now that memory
is under control:
  - MAX_FEED_SIZE 30 → 200 (v0.12.6 baseline)
  - fetchFollowFeed limit 30 → 100
  - fetchGlobalFeed fetch 80 → 100
  - Following tab slice 30 → 100

The earlier 30-caps were themselves OOM firefighting that shipped
in v0.12.7 and were no longer needed.

Memory verified 2026-04-16: oscillates 1.1-1.6 GB across all tabs
(Global / Following / Trending / Media / profile / thread) under
heavy use with embedded relay enabled. No crashes. Elastic cache
behaviour rather than monotonic leak — memory spikes briefly on
content loads and reclaims within seconds.

See private_docs/WEBKIT_OOM_INVESTIGATION.md for the full
investigation (4 days of chasing symptoms before finding the
one-line regex as the real cause).

src-tauri/Cargo.lock

@@ -5320,7 +5320,7 @@ checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426"
 
 [[package]]
 name = "vega"
-version = "0.12.7"
+version = "0.12.8"
 dependencies = [
  "futures-util",
  "hex",