WAF path.prefix matches on raw startsWith, so /admin also matches /administrator

`path.prefix` compiles to a raw `String.prototype.startsWith`:

```
(prefix == null || request.path.startsWith(prefix)) &&
```

So a rule with `path: { prefix: "/admin" }` also matches `/administrator`, `/admin-tools`, and `/adminish`. For a `block` action that is over-blocking rather than under-blocking, which is the safer direction, but it is still a surprise: an operator scoping a rule to an admin area gets unrelated routes.

Arguably this is what "prefix" literally means, which is why this is low priority rather than a straightforward bug — the question is whether the rule-authoring contract should offer segment-aware matching, not whether `startsWith` is implemented correctly.

**Options:**

- Document that `prefix` is a raw string prefix and point authors at `path.regex` for segment-aware matching. Cheapest, and may be enough.
- Add a segment-boundary variant (match only when the next character is `/` or end-of-string), either as a new field or an option on `prefix`.

Found by cross-model review while reviewing an unrelated change; not customer-reported. The WAF is unreleased — `main` and `v5.3.0-alpha.1` only.

Start with the path.prefix compilation shown in the issue, then compare its contract with path.regex and any WAF rule-authoring guidance. Resolve whether the project should document raw-prefix behavior or introduce segment-aware matching; done means the chosen behavior and authoring contract are explicit.

Written by the indexing model from the issue text.