[MCP] parsePath attribute-suffix routing doesn't resolve for programmatic static-properties Resources

[kylebernhardy]

Follow-up from #1920 / PR #1921 (cross-model review finding, adjudicated out-of-scope there).

Resource.parsePath resolves URL attribute-suffix routes (e.g. GET /Widget/id.label) by reading this.attributes directly:

(this as any).attributes?.find((a) => a.name === suffix)

A programmatic Resource that declares only static properties (no attributes Array) has attributes === undefined, so attribute-suffix routing silently doesn't resolve for it. This is a pre-existing gap (not introduced by #1921, which only touched schema derivation), surfaced now that #1921 makes static properties a first-class schema source.

Why not fixed in #1921

parsePath is a per-request hot path. The schema-derivation surfaces (#1921) use resolveAttributes(...), which projects properties → attributes on each call when attributes is empty — fine on the cold registration/introspection paths, but projecting on every request in parsePath is not acceptable.

Suggested approach

Cache the projected attribute Array on the class the first time it's needed (e.g. a lazily-computed #resolvedAttributes memo, invalidated on schema reload), then have parsePath (and any other per-request .attributes reader) use the memo. resolveAttributes from resources/jsonSchemaTypes.ts is the projection to reuse.

Acceptance

• GET /X/id.field resolves for a programmatic Resource declaring static properties.
• No per-request projection cost (memoized).
• A test covering attribute-suffix routing on a programmatic static properties Resource.

Issue generated by kAIle (Claude Opus 4.8).

[kriszyp]

From dispatch finding (task qa-wave-2026072323):

• F-194 — attribute-suffix PUT on a programmatic static-properties Resource returns 200 and silently writes a phantom character-indexed record. PUT /ProgWidget/w1.color body "blue" → 200 {"ok":true} and a new record at the literal id "w1.color": {"0":"b","1":"l","2":"u","3":"e","id":"w1.color"}; w1 is untouched. Same one-line root cause as the already-filed #1922 (which reports only the GET arm, a clean 404): resources/Resource.ts:392 resolves the suffix via (this as any).attributes?.find(...), which is undefined for a Resource declared with static properties, so the suffix is never stripped. The write arm is the more serious face — silent data creation behind a success response.