Wildcard matching inner domain. Either a doc discrepancy, or unclear.

### Existing documentation URL(s)

- https://developers.cloudflare.com/workers/configuration/routing/routes/

### What changes are you suggesting?

On the [Routes page](https://developers.cloudflare.com/workers/configuration/routing/routes/), in the "Hostnames may optionally begin with `*`" section, the example table contains an internal contradiction that I'd like clarified or corrected.

The table states:

| Request URL | `*example.com/*` |
| ----- | ----- |
| `https://myexample.com/` | Matches |
| `https://not-example.com/` | Does not match |

Based on the rule stated earlier on the same page — "The only supported operator is the wildcard (`*`), which matches zero or more of any character" — I cannot see why these two cases would behave differently. In both URLs, the `*` prefix would match the characters preceding `example.com` (`"my"` in one case, `"not-"` in the other), and the trailing `/*` would match the empty path. By the documented rule, both should match.

This is also reinforced by the warning immediately above the table, which states that `*example.com` "will also match hostnames that are not subdomains of `example.com`" and recommends using two separate routes (`example.com/*` and `*.example.com/*`) to avoid this. That warning agrees with the interpretation that `not-example.com` *should* match — which makes the last row of the table the outlier.

There are two possibilities, and either would require a documentation change:

1. **The table is wrong.** If the wildcard truly matches zero or more of any character, then `https://not-example.com/` should say "Matches." The row should be corrected.
2. **The table is correct, but the rule is incompletely described.** If there is some additional constraint in the matching implementation — for example, that certain characters (hyphens, non-alphanumerics, etc.) terminate the wildcard match at a hostname boundary — that constraint needs to be documented. As written, the rule does not explain why `"my"` is an acceptable wildcard match but `"not-"` is not.

I have not purchased domains to empirically verify which case is true, so I'm raising this as a consistency issue rather than asserting which side is incorrect.

**What is the expected outcome?**

Either:

1. The `not-example.com` row in the table is updated to "Matches" to align with the stated wildcard semantics and the warning above the table, **or**
2. The rule description is expanded to document the actual matching behavior — specifically, what additional constraints apply to the `*` wildcard in the hostname position that cause `myexample.com` to match but `not-example.com` not to.

### Additional information