Routing parity: TS path-wide exec deny; Go matchEndpoint accepts endpoint subpaths

[abienkowski]

Problem

Two further pre-existing routing divergences between the equal-peer implementations, surfaced during the merge-gate review of #43 (both set aside there as out of scope):

1. TS denies exec anywhere in the path. ts/src/proxy.ts (~line 35) rejects any path containing an /exec segment, so e.g. GET /images/exec is denied in TypeScript but allowed (passthrough) in Go and Rust.
2. Go's matchEndpoint accepts subpaths of exact endpoints. POST /containers/create/extra reaches routeCreate in Go, while Rust and TypeScript exact-match the endpoint and fall through to default-deny.

Impact

Low severity. Neither is exploitable by itself (gates still apply to whatever is routed), but which requests reach the daemon — and which gate chain they go through — depends on the implementation language, which the equal-peers rule exists to prevent. Behaviour should converge; in both cases the stricter behaviour looks correct (deny POST /containers/create/extra everywhere; scope TS's exec check to the positions Go/Rust check).

Proposed solution

Decide the canonical row for each case, converge all three implementations, and pin each row with same-named unit tests in all three languages plus integration checks — the #24/#43 pattern. The Quint routing model should gain the two rows as well so the table stays the source of truth.

Alternatives considered

• Leaving them documented-but-divergent: rejected — Go router doesn't exclude reserved path segments in extractContainerName (cross-language parity) #24 established that routing divergences get fixed, not catalogued.
• Bundling with the empty-name divergence fix: possible if a maintainer prefers one PR; filed separately because the empty-name case has a clear one-line fix while these two need a canonical-behaviour decision first.

Which implementation(s) would this affect?

• Go
• Rust
• TypeScript

[abienkowski]

A third case in this family, confirmed during the #51 merge-gate review by running the Go router directly:

• DELETE /containers/<name>/exec — Go's exec check (matchEndpoint(path, "containers", "exec")) matches exec only in the name position, so this path takes the lifecycle branch and is allowed and forwarded. Rust (path.contains("/exec") after the /containers/ prefix check) and TypeScript (path.includes("/exec")) both deny it.
• Related: POST /containers/<name>/exec is denied in Go too, but by default-deny rather than the exec check — the three implementations agree on the status for that one, for different reasons.

Observed outputs (Go router, built from main):

DELETE /containers/mycontainer/exec -> Allow (forwarded)
POST   /containers/mycontainer/exec -> Deny  "endpoint ... is not allowed"
DELETE /containers/exec             -> Deny  "exec is not allowed"

So when converging the exec rule, the decision isn't only about TS being too broad — Go is too narrow. spec/README.md's Modeling Notes (post-#51) document this divergence and point here. Note deploy/test.sh's POST /containers/*/exec -> 403 check passes for different reasons per language today.