Subscription import: bundled fkYAML crashes on crafted Clash YAML (memory-safety) #1746

Bundled fkYAML (Clash subscription parsing) crashes on crafted YAML — memory-safety bugs

RawUpdater::updateClash (src/configs/sub/GroupUpdater.cpp) parses a subscription body with:

fkyaml::node node = fkyaml::node::deserialize(str.toStdString());
clash::Clash clash_config = node.get_value<clash::Clash>();

wrapped in try { ... } catch (const fkyaml::exception&). Fuzzing the bundled fkYAML
(3rdparty/fkYAML/node.hpp, v0.4.2) with libFuzzer + ASan/UBSan found several memory-safety bugs
in the deserializer that are reachable from a malicious subscription provider:

• stack-buffer-overflow (READ) in get_buffer_view_utf16 — 3-byte input 01 00 0a
• heap-buffer-overflow (READ) in get_buffer_view_utf8 — ~3-byte input
• SEGV from m_context_stack.back() on an empty deque in deserialize_scalar
• (plus a UBSan left-shift-of-negative and a few other crash sites)

The catch (fkyaml::exception&) does not catch these — an OOB access / SEGV is not a C++
exception — so a crafted Clash YAML crashes the client on subscription update. Threat model:
"add my subscription URL" / a compromised or malicious sub endpoint.

Important: these reproduce on the latest upstream fkYAML v0.4.3 as well, so bumping the
vendored copy does not fix them. They are upstream fkYAML bugs; I reported them upstream: fktn-k/fkYAML#536. Filing here so Throne is aware its subscription import is affected.

Possible mitigations until an upstream fix: run subscription YAML parsing with fault isolation
(separate process/worker), or pre-validate/normalize input encoding before deserialize.

Minimal reproducers available on request.