port the \uXXXX UTF-8 decode fix to the el-compiler runtime copy

Same defect as the release runtime: \uXXXX was skipped and a literal '?'
emitted, destroying every non-ASCII character in JSON entering the runtime.
Two copies of one parser bug is how this class of fault survives a fix, so
it lands in both.

NOTE: this file also carries pre-existing uncommitted work from 2026-07-15/16
that this commit preserves rather than authors - loopback bind hardening
(EL_HTTP_BIND_HOST) and per-install API-key auth (EL_HTTP_AUTH_KEY) for the
shipped desktop build, plus goal-bias and node-json changes. It had been
sitting in the working tree for three weeks. Committing it because
uncommitted work is work that does not survive, which is the same durability
lesson as yesterday's Hebbian write-back finding. It needs review on its own
terms - see the backlog item for reconciling the two runtime copies.

lang/el-compiler/runtime/el_runtime.h

@@ -632,6 +632,7 @@ el_val_t  engram_load(el_val_t path);
  * can pass results straight through without round-tripping ElList/ElMap
  * through json_stringify. */
 el_val_t  engram_get_node_json(el_val_t id);
+el_val_t  engram_get_node_by_label(el_val_t label);
 el_val_t  engram_search_json(el_val_t query, el_val_t limit);
 el_val_t  engram_scan_nodes_json(el_val_t limit, el_val_t offset);
 el_val_t  engram_scan_nodes_by_type_json(el_val_t node_type, el_val_t limit, el_val_t offset);