engram: fix silently-wrong query params, and make el_seed.o + el_runtime.o link

Three real bugs, all found by actually running the thing rather than reading it.

1. query_param never URL-decoded. A GET of /api/search?q=neural%20network
   searched for the literal string "neural%20network" and returned []. Every
   multi-word search against the live engram has been silently returning empty
   results — not an error, an empty result, which is why it went unnoticed.
   Affects every GET route that reads query params, not just search.

2. query_param matched key names unanchored. str_index_of(qs, "q=") matches
   inside "faq=", so "?faq=X&q=Y" returned X for key "q". Verified live before
   the fix. Now searches for "&key=" against "&"+querystring so a match can
   only land on a real parameter boundary.

3. el_request_start/el_request_end were defined in BOTH el_seed.c and
   el_runtime.c, so linking the two objects together — which is exactly what
   the product build does — failed with duplicate symbols. el_seed.c's own
   comment already says these moved there ("formerly defined in el_runtime.c.
   Now self-contained in el_seed.c"); the el_runtime.c copies were left behind
   during that move. Removed them, kept declarations since http_worker calls
   them. Also added the three missing prototypes (engram_op_assert_json,
   engram_node_full_in, engram_connect_in) that el_seed.c wraps but never
   declared, which made it fail to compile standalone under C99+.

Verified: engram builds and links clean from canonical source; before/after
comparison on a copy of the real store shows "neural network" returning a real
match where the live build returns [], and "?faq=WRONG&q=MetaColloc" now
resolving to MetaColloc. Live engram on :8742 was never touched.

engram/src/server.el

@@ -41,17 +41,29 @@ fn strip_query(path: String) -> String {
     str_slice(path, 0, q)
 }
 
+// query_param — extract one query-string value, URL-DECODED.
+//
+// The decode step was missing (found 2026-08-15): a claim sent as
+// "test%20claim" arrived at engram_assert_json still percent-encoded and was
+// stored/compared that way, so any value containing a space, &, =, or non-ASCII
+// character silently became a different string than the caller sent. Affects
+// every GET route that reads params this way, not just /api/assert.
 fn query_param(path: String, key: String) -> String {
     let q: Int = str_index_of(path, "?")
     if q < 0 { return "" }
     let qs: String = str_slice(path, q + 1, str_len(path))
-    let needle: String = key + "="
-    let pos: Int = str_index_of(qs, needle)
+    // Anchor the match to a real key boundary: prefixing "&" and searching for
+    // "&key=" means "q" can never match inside "faq=". (Found 2026-08-15:
+    // "?faq=X&q=Y" returned X for key "q" — a silently wrong value, not an
+    // error.) The leading "&" makes the first parameter match the same way.
+    let hay: String = "&" + qs
+    let needle: String = "&" + key + "="
+    let pos: Int = str_index_of(hay, needle)
     if pos < 0 { return "" }
-    let after: String = str_slice(qs, pos + str_len(needle), str_len(qs))
+    let after: String = str_slice(hay, pos + str_len(needle), str_len(hay))
     let amp: Int = str_index_of(after, "&")
-    if amp < 0 { return after }
-    str_slice(after, 0, amp)
+    let raw: String = if amp < 0 { after } else { str_slice(after, 0, amp) }
+    return __url_decode(raw)
 }
 
 fn query_int(path: String, key: String, default_val: Int) -> Int {