caveman-shrink: "make sure" / "be sure" collapse to "make" / "be" — is dropping "sure" inside those collocations intended?

src/mcp-servers/caveman-shrink/compress.js lists sure in PLEASANTRIES, so it is removed wherever it stands alone. That is right for "Sure, this returns the value", but the same rule fires inside "make sure" and "be sure", where "sure" is not a pleasantry but the verb's object. The result is an instruction with a hole in it.

Reproduce (current main):

node -e 'const {compress}=require("./src/mcp-servers/caveman-shrink/compress.js");
for (const t of ["Make sure the file exists.","Make sure to call init before any other tool.","Be sure to pass an absolute path.","Not sure why this fails."]) console.log(JSON.stringify(t),"=>",JSON.stringify(compress(t).compressed));'

"Make sure the file exists."                    => "Make file exists."
"Make sure to call init before any other tool." => "Make to call init before any other tool."
"Be sure to pass an absolute path."             => "Be to pass absolute path."
"Not sure why this fails."                      => "Not why this fails."

In the first case the meaning is inverted, not just weakened: "Make sure the file exists" is a check, while "Make file exists" reads as "create the file".

Why it matters compressDescriptionsInPlace rewrites MCP tool descriptions on tools/list, so "Make to call init before any other tool" is what the model reads as the tool's contract. "Make sure to X first" is one of the most common phrasings in tool descriptions (the existing test compresses real MCP-style description uses "Please make sure to provide the location as a city name" as its sample input, though it only asserts that "city name" survives). This goes against the spirit of CONTRIBUTING's rule that compressors must never silently corrupt a payload, and it has the same shape as the hyphenated-compound corruption fixed in #1055 (just-in-time → -in-time): a word that is a filler on its own is not a filler inside a fixed collocation.

Question Is removing "sure" inside "make sure" / "be sure" / "not sure" intended, or should the pleasantry rule skip those collocations (e.g. a negative lookbehind for make|be|not, or keeping "sure" only when it is sentence-initial and followed by a comma)? Happy to send a PR with a regression test once the intended behaviour is confirmed. The same question applies to the hedge might ("might be null" → "be null"), but that one at least drops a hedge rather than the object of a verb, so I am raising only the "sure" case here.