fix: reject path template holes that share a segment with literal text

[OmarAlJarrah]

Summary

• PathTemplate.parse never required a {hole} to sit at a / boundary, so a literal prefix or suffix sharing a path segment with a hole (e.g. /reports/{id}.json or v{version}) got silently re-segmented when the URL was built: BindingExecutor's appendTokenSegments splits every Literal token on / and adds every Hole token as its own segment, regardless of whether it was adjacent to literal text in the template.
• @PathTemplate frames itself as a "Go-style path template", and net/http.ServeMux wildcards must occupy a full path segment, so the fix rejects a boundary violation at parse time (fail fast) rather than trying to keep same-segment literal/hole runs together during composition. A hole is still allowed to sit directly against another hole with no literal between them ({a}{b}), since neither side can be split.
• Documented the new constraint on the @PathTemplate KDoc.

Test plan

• ./gradlew :kuri-bind:jvmTest — added regression tests reproducing both issue examples (/reports/{id}.json with id=5, v{version} with version=2) at both the PathTemplate.parse level and end-to-end through BindingExecutor; confirmed they failed before the fix and pass after.
• ./gradlew :kuri-bind:ktlintCheck
• ./gradlew :kuri-bind:detekt
• ./gradlew :kuri-bind:apiCheck (no public API shape change — kuri-bind is JVM-only, so no jsNodeTest/native leg applies here)

Closes #82