Probe Linear's real comment-body and rate-limit behaviour (32767 is borrowed from Jira, unmeasured)

[dean0x]

Context

Tracker Phase 3 (#325, tracking #321) ships the Linear provider at rank 4 (post-with-warning dedup — no author filter, no entity-property dedup) because a stock official Linear MCP exposes no viewer/"me"/identity tool and create_attachment is a base64 upload rather than a URL-link form, making Linear's documented URL idempotency unreachable. The module also caps comment bodies at 32767 characters and treats HTTP 400 RATELIMITED as the rate-limit STOP trigger. Neither the 32767 cap nor the RATELIMITED behaviour was measured against a real Linear workspace — 32767 is borrowed from the Jira module's own cap, not derived from Linear's actual API limits.

What to probe

• The real Linear comment-body character/byte limit (confirm or replace the borrowed 32767)
• The actual rate-limit error surface on a live workspace, and whether it exposes a Retry-After-equivalent header or field
• Whether a stock official Linear MCP server exposes any viewer/"me"/identity tool (re-check across current MCP catalogs — six were checked at design time and none had one)
• Whether create_attachment accepts a URL-link form on any current server, or remains base64-only (this decides whether URL idempotency becomes reachable)
• Any other gap named in _linear.mds's ## Known Unknowns section at the time this issue is picked up

Where the borrowed values live

• src/assets/mds/tracker/_linear.mds — the mechanics module carrying the 32767 cap and the RATELIMITED STOP trigger (lands in Phase 3c)
• tests/provider-literals.test.ts — pins 32767 and RATELIMITED as tested literals (lands in Phase 3c)

Acceptance

Values are measured against a live Linear workspace; _linear.mds and tests/provider-literals.test.ts are re-pinned to the measured values (or confirmed unchanged); Linear's dedup rank is re-assessed in light of the identity-tool and attachment-URL findings.

Related

Part of #321 · Follows #325