tree: refuse to let a regexp placeholder match a slash across segments

[piyush295]

Bug (fixes #1188)

A regexp placeholder with a non-slash tail could span path segments. For a pattern like /re/{name:[^.]+}.json, the segment-end delimiter chi uses is the first byte of the suffix (.), not /. If the user's regexp did not itself exclude /, the capture could include one:

GET /re/a.json      -> 200 name="a"
GET /re/a/b.json    -> 200 name="a/b"   # bug: regexp matched across segments
GET /bare/a/b       -> 404
GET /plain/a/b.json -> 404

The "URL patterns" documentation in chi.go says of a regexp placeholder that / will never match. The ntParam branch already enforces this with a strings.IndexByte(xsearch[:p], '/') != -1 check. The ntRegexp branch didn't.

Fix

After a successful regexp match in the ntRegexp branch, apply the same cross-segment guard: if the matched substring contains a /, skip the node. This holds the public contract regardless of what the user regexp allows.

Test

TestMuxRegexpPlaceholderWithSuffixDoesNotMatchSlash registers both /re/{name:[^.]+}.json and /plain/{name}.json and asserts:

• Single-segment inputs still match (/re/a.json → name="a", /plain/a.json → name="a").
• Slash inside the placeholder value is 404 for both forms (/re/a/b.json, /plain/a/b.json).

go test ./... passes (both chi and chi/middleware).