docs(copilot): state the actual bound on the thinking nesting rule

The docstring implied generics are excluded from the marker check. They are not:
the match is a substring test, so `Promise<void>` is safe only because `void` is
not a tag name, while `Promise<options>` does match and would release a thinking
body as text.

Says so plainly now, with why it is left as-is: the boundary check that would
narrow it wants a lookbehind, which is Safari 16.4+ and would be a parse-time
SyntaxError on the versions this app still supports — a dead client chunk is a
worse outcome than the bug. Reaching it also needs an inline `<thinking>` body,
which the agent no longer emits, discussing a type named exactly after a tag.

Comment only; no behaviour change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: j15z

apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/special-tags/special-tags.tsx

@@ -639,6 +639,13 @@ function isViableJsonPrefixOf(scannable: string): boolean {
  * would itself act on proves the enclosing opener was text. Shared so the
  * streaming and matched-pair paths cannot answer the same question differently
  * — them disagreeing is what let a late close swallow content already on screen.
+ *
+ * The match is by substring, so a generic is safe only when its parameter is not
+ * itself a tag name: `Promise<void>` does not match, `Promise<options>` does. The
+ * narrowing is not worth its cost — it needs a `<thinking>` body, which the agent
+ * no longer emits (reasoning arrives as structured thinking blocks), discussing a
+ * type named exactly after a tag; and the boundary check that would fix it wants a
+ * lookbehind, unavailable on the Safari versions this app still supports.
  */
 function hasSpecialTagMarker(text: string): boolean {
   return SPECIAL_TAG_NAMES.some((name) => text.includes(`</${name}>`) || text.includes(`<${name}>`))