docs: address PR #196 review; update research decisions and PRD

Research doc: close open questions with decisions from review — hard
cutover on path_allowlist, drop glob (regex sufficient), stick with
Gateway API OR semantics for headers, case-insensitive method names.

PRD 0053: adopt Gateway API HTTPRoute match vocabulary (paths, methods,
headers) as the route schema replacement for path_allowlist. Add
MatchEntry / PathMatch / HeaderMatch types to EgressRoute design; cite
the route matching research doc; fold match restructure into chunk 1
alongside the dlp block.

docs/research/yaml-route-matching-formats.md

@@ -407,23 +407,20 @@ egress:
 All predicates within `match` are ANDed. A list of `paths` entries is
 ORed (first match wins — same as the current `path_allowlist` semantics).
 
-### 2. Path type enum (`exact` | `prefix` | `glob` | `regex`)
+### 2. Path type enum (`exact` | `prefix` | `regex`)
 
-Use four named types rather than inferring from the value's syntax. This
+Use three named types rather than inferring from the value's syntax. This
 avoids the ambiguity that plagues `.gitignore` and `nginx location` patterns
 where the same string can mean different things depending on leading characters.
 
 - `prefix`: mirrors current `path_allowlist` semantics.
-- `glob`: adopts ALB-style `*` (single segment) and `**` (multi-segment,
-  covering `/api/*/data` and `/api/**/data`). Simpler for operators than
-  writing regex.
-- `regex`: RE2 for advanced cases. Reject at load time if the pattern fails
-  to compile.
+- `regex`: RE2 for wildcard and advanced cases. Reject at load time if the
+  pattern fails to compile. Covers every case glob would handle —
+  `/api/[^/]+/data` is the `/api/*/data` equivalent.
 
-**Glob semantics decision needed:** ALB's `*` matches across `/`; most
-shell-glob conventions treat `*` as intra-segment and `**` as cross-segment.
-The shell convention (`*` = no slash, `**` = slash-crossing) is less
-surprising to operators and avoids accidental over-matching.
+Glob-style syntax is not included: it adds a third path-matching language
+on top of prefix and regex without meaningful operator benefit, since regex
+is already required for any non-trivial wildcard.
 
 ### 3. Header matching as a list of `{name, value, type}` objects
 
@@ -469,18 +466,22 @@ predicates.
 
 ---
 
-## Open questions
+## Decisions
 
-1. **Backward compatibility:** `path_allowlist` is the current field. If
-   adopting a `match`/`matches` structure, keep `path_allowlist` as a
-   deprecated alias? Or treat this as a breaking manifest version bump?
-2. **Glob segment semantics:** adopt shell convention (`*` = intra-segment,
-   `**` = cross-segment) or ALB convention (`*` = anything including `/`)?
-   The shell convention is safer; ALB's is simpler.
-3. **Header value OR:** Gateway API requires a separate match entry to OR
-   header values. ALB allows multiple values in one condition. Which is
-   less surprising for bot-bottle operators? The ALB approach is more
-   concise for the common case (e.g., `Content-Type: [application/json,
-   application/x-www-form-urlencoded]`).
-4. **Case sensitivity on method names:** normalize to uppercase at parse
-   time (fail on unrecognised values) or case-insensitively?
+The open questions raised during research were resolved in PR #196 review:
+
+1. **Backward compatibility:** Hard cutover. The new `matches` structure
+   replaces `path_allowlist` entirely with no compatibility shim and no
+   fallback parsing for the old format. Manifests using `path_allowlist`
+   must be migrated.
+
+2. **Glob support:** Dropped. Not strictly necessary — `regex` covers every
+   case glob would handle. Fewer path-matching languages to document and
+   validate.
+
+3. **Header value OR:** Stick with Gateway API. OR across header values
+   requires a separate entry in the `matches` list, not multiple values
+   inside one `headers` block.
+
+4. **Method name case:** Case-insensitive at parse time. `get`, `GET`, and
+   `Get` are all accepted and normalised to uppercase internally.