Truncate issue body to GitHub's 65536 character limit

[Copilot]

GitHub rejects issue creation when the body exceeds 65536 characters. Large lake build outputs in create-issue.sh can easily trigger this.

Change

Rather than truncating the assembled BODY as a whole (which could cut inside the fenced code block and leave the closing ``` missing), the implementation reserves space for the static prefix and suffix first, then truncates only BUILD_OUTPUT if it exceeds the remaining budget:

PREFIX="$DESCRIPTION

Files changed in update:$BULLET_LIST

## Build Output

\`\`\`
"
SUFFIX="
\`\`\`
"
TRUNCATION_NOTICE="
...(truncated)"
MAX_BODY_LEN=65536
AVAILABLE=$((MAX_BODY_LEN - ${#PREFIX} - ${#SUFFIX}))
if [ ${#BUILD_OUTPUT} -gt $AVAILABLE ]; then
  TRUNCATE_AT=$((AVAILABLE - ${#TRUNCATION_NOTICE}))
  BUILD_OUTPUT="${BUILD_OUTPUT:0:$TRUNCATE_AT}$TRUNCATION_NOTICE"
fi
BODY="$PREFIX$BUILD_OUTPUT$SUFFIX"

This ensures the closing code fence is always present and the issue body is valid Markdown even when the build log is very large. ${#...} counts characters (not bytes), matching GitHub's character-based limit.

[Seasawher]

@copilot メッセージは日本語ではなくて英語で表示してください

[Copilot]

Changed to English only in 02abf9a: the notice now reads ...(truncated).

[Seasawher]

@copilot

結論：このままでも主目的はだいたい満たすが、markdown が壊れるので修正推奨です。

主な変更は BODY 作成後に 65536 文字を超えたら末尾を切って ...(truncated) を付けるものです。差分は scripts/create-issue.sh に9行追加だけです。 

問題点：

1. コードフェンスが閉じられない可能性が高い
   BUILD_OUTPUT は ``` の中に入っていますが、現在の実装は BODY 全体を途中で切るため、長いログで切れると末尾の closing fence が消えます。
   つまり issue 本文の Markdown が壊れます。該当構造は main 側の BODY 組み立て部分で確認できます。 
2. 切る対象は BODY 全体ではなく BUILD_OUTPUT に限定した方がよい
   問題原因は large lake build output とPR本文にも書かれているので、DESCRIPTION や changed files まで巻き込んで切るより、ログ部分だけを予算内に収める設計の方が安全です。 
3. テストがない
   少なくとも「65536未満」「65536超過」「超過時も closing fence が残る」の3ケースは shell test か簡易スクリプトで確認したいです。

提案コメント：

This fixes the immediate API error, but I think we should truncate BUILD_OUTPUT rather than the whole BODY.
With the current implementation, if truncation happens inside the fenced build-output block, the closing ``` is removed, so the generated issue body has broken Markdown. It would be safer to compute the available budget after reserving space for the prefix, truncation notice, and closing code fence, then truncate only BUILD_OUTPUT.
Something like:

PREFIX="$DESCRIPTION
Files changed in update:$BULLET_LIST
## Build Output
\`\`\`
"
SUFFIX="
\`\`\`
"
TRUNCATION_NOTICE="
...(truncated)"
MAX_BODY_LEN=65536
AVAILABLE=$((MAX_BODY_LEN - ${#PREFIX} - ${#SUFFIX}))
if [ ${#BUILD_OUTPUT} -gt $AVAILABLE ]; then
  TRUNCATE_AT=$((AVAILABLE - ${#TRUNCATION_NOTICE}))
  BUILD_OUTPUT="${BUILD_OUTPUT:0:$TRUNCATE_AT}$TRUNCATION_NOTICE"
fi
BODY="$PREFIX$BUILD_OUTPUT$SUFFIX"

This preserves the Markdown structure even when the build output is very large.

判定：**Request changes 寄り**。機能の方向性は正しいですが、ログが長いと Markdown が壊れるので、merge 前に直した方がよいです。

[Copilot]

@copilot

結論：このままでも主目的はだいたい満たすが、markdown が壊れるので修正推奨です。...

Fixed in e0cd185. The truncation now happens on BUILD_OUTPUT before BODY is assembled: the prefix and suffix (including the closing ```) are reserved, and only the build log is cut if the budget is exceeded. The closing fence is always present regardless of truncation.