fix(sandbox): strip query string from L7 path matching

Previously, L7 policy path rules received the full request URI including
the query string. This caused exact path rules like `path: /api/v1/download`
to silently fail when clients added query parameters (e.g.,
`/api/v1/download?slug=foo`), because Rego's glob.match treats the query
string as part of the last path segment.

This fix splits the request target into path and query components during
HTTP parsing. Path rules now match only the path component, and query
strings are passed through transparently to the upstream server. This
matches user expectations: a path rule controls which endpoints are
reachable, not which query parameters are allowed.

Changes:
- Add `query` field to L7Request and L7RequestInfo structs
- Split path/query in parse_http_request before L7 policy evaluation
- Pass query string to Rego input for future query param filtering
- Add l7_query field to L7_REQUEST log output
- Add tests for query string splitting and path matching with query params
- Document path matching behavior in policy-schema.md

Refs: /discussions/607

Author: johntmyers

docs/reference/policy-schema.md

@@ -198,6 +198,12 @@ Used when `access` is not set. Each rule explicitly allows a method and path com
 | `allow.path` | string | Yes | URL path pattern. Supports `*` and `**` glob syntax. |
 | `allow.query` | map | No | Query parameter matchers keyed by decoded param name. Matcher value can be a glob string (`tag: "foo-*"`) or an object with `any` (`tag: { any: ["foo-*", "bar-*"] }`). |
 
+**Path matching behavior:**
+
+- Path rules match only the path component of the request URI (everything before `?`).
+- Query strings are not evaluated by path rules. A rule with `path: /api/v1/download` matches both `/api/v1/download` and `/api/v1/download?slug=my-skill&version=1.0`.
+- Glob patterns use `/` as the segment delimiter. `*` matches within a single segment, `**` matches across segments.
+
 Example with rules:
 
 ```yaml