routing: multi-param routes + query string + a cleaner DSL surface

context

the routing layer (spin.rb) is sinatra-flat and AOT-compiles: spin_get?,
spin_match?, spin_param, etc., dispatched via if/elsif. it works
(verified GET/POST/DELETE, single :param, arity-based 404). but it's v0.

limitations to address

• one param per route. spin_param returns the FIRST :param only.
  need /a/:x/b/:y → both. (probably spin_param(pattern, path, name)
  or return a small homogeneous structure — constrained by spinel, see #1.)
• no query string parsing. QUERY_STRING is in ENV but unparsed.
  add spin_query(name).
• no header access helper. HTTP_* are in ENV; add spin_header.
• wildcard / prefix routes (/assets/*)?
• 405 vs 404. currently everything unmatched is 404; a path that
  matches but with the wrong method should arguably be 405. (the WEBrick
  shim also rejects DELETE pre-dispatch — see #transport notes.)

the tension to respect

spinel has no runtime proc-table (heterogeneous proc-in-array breaks
inference). do NOT try to build get("/x") { ... } — it won't compile. keep
the flat-dispatch model; just make the helpers richer. validate every
addition actually compiles before merging.

stretch

could a spin CLI generate the if/elsif dispatch from a more compact route
table at build time (macro-expand, not runtime)? that would get sinatra
ergonomics with AOT dispatch. design spike.

Start in spin.rb with the existing spin_get?, spin_match?, and spin_param helpers and the flat if/elsif dispatch. Review how ENV carries QUERY_STRING and HTTP_* values, and inspect the WEBrick shim's DELETE handling. Define a smaller, focused scope before changing behavior, then verify each addition compiles under the AOT constraints.