📝 docs(tsl): clarify syntax constraints and enhance test infrastructure

- Add TSF file naming constraint to syntax/02_core_model.md
- Clarify semicolon rules: syntax facts vs style preferences
- Separate control flow end semicolon rules (syntax allows both)
- Add function body semicolon requirements to syntax/05_functions_and_calls.md
- Move style preferences to code_style.md (control flow end semicolons)
- Remove cross-references from syntax docs to maintain independence
- Enhance Gitea workflow emoji for better CI output readability
- Fix CI test path from tests/ to test/
- Organize agent test results under test/agent/result/ directory
- Add complete Chinese translation of test cases (test_cases_zh.md)
- Clean up .gitignore to use unified test/agent/result/ directory
- Remove obsolete agent test artifacts (REPORTS_LOCATION.md, old results)

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

docs/tsl/code_style.md

@@ -4,7 +4,7 @@
 是否可直接用于生成代码：仅部分
 是否含可直接照写示例：否
 是否含不可照写反例：否
-遇到不确定时：[naming.md](naming.md)、[syntax/index.md](syntax/index.md)、[toolchain.md](toolchain.md)
+遇到不确定时：风格/命名看 [naming.md](naming.md)；语法事实看 [syntax/index.md](syntax/index.md)；验证命令或自动化入口只看项目脚本、CI，或目标项目已真实填写且没有 `<...>` 占位符的 [toolchain.md](toolchain.md)
 
 本页记录本仓库代码风格偏好，不代表 TSL 语法事实。
 
@@ -22,20 +22,19 @@
 ### 1.1 单一职责
 
 - 一个文件只做一件事；职责明确。
-- `.tsl` 作为可执行脚本：语句区在前并按顺序执行；需要本文件函数/类时，声明区放在语句区之后。
-- `.tsf` 作为模块/函数扩展文件：可复用逻辑下沉到 `.tsf`，部署到解释器 `funcext` 后供脚本调用。
+- 文件模型和顶层声明规则以 `docs/tsl/syntax/02_core_model.md` 为准；本页只规定组织偏好。
+- 可复用逻辑优先集中到可复用声明文件；入口/编排层只保留必要流程。
 - 当一个顶层声明同时承担“协议适配 + 业务计算 +
   I/O/环境依赖 + 临时代码”时，优先拆分边界：核心纯逻辑 → 工具函数 → 边界适配（I/O）。
 
-### 1.2 文件名与顶层声明（硬约束）
+### 1.2 文件名与顶层声明
 
-- TSL 语法要求（仅 `.tsf`）：每个 `.tsf`
-  文件只能有一个顶层声明，且文件基名必须与顶层声明同名。
-- `.tsl` 允许直接写语句，不要求顶层声明；文件名不强制，但建议清晰可检索。
-- `.tsl` 中如果同时需要脚本语句和函数/类声明，先写语句区，再写声明区；不要在声明区后继续追加脚本语句。
+- 文件模型和顶层声明规则以 `docs/tsl/syntax/02_core_model.md` 为准；文件和实体如何命名见
+  `docs/tsl/naming.md`。
+- 文件名不强制表达完整职责，但应清晰可检索。
 - 推荐文件名使用 `PascalCase` 以提升检索与协作一致性；扩展名按类型使用
   `.tsl`/`.tsf`（两者都属于 TSL 源文件，风格规则一致）。
-- 详细约束与命名细则见 `docs/tsl/naming.md`。
+- 重命名时同步检查引用、调用点、项目配置和文档链接。
 
 ### 1.3 依赖与分层
 
@@ -92,6 +91,7 @@ end
 - 多语句分支使用 `begin/end` 包裹：在 `then/else` 后换行写 `begin`，`end`
   单独成行。
 - `else/elseif` 等分支关键字另起一行，与上一块的 `end` 对齐。
+- 控制流块（`if`/`while`/`for`/`case`/`try` 等）的 `end` 后不加分号；顶层声明（函数/过程/类/`unit`）的 `end` 后加分号（这是语法要求，见 `syntax/05_functions_and_calls.md` 和 `syntax/09_units_and_scope.md`）。
 - 单语句分支可省略 `begin/end`（保持清晰优先；一旦分支变复杂就回退到块结构）：
 
 代码块身份：配置片段 / 概念骨架
@@ -195,8 +195,8 @@ count := count + 1;
 
 ## 4. 代码实践（Best Practices）
 
-> 本节偏“实践建议”（should），用于提升可读性/可测试性；若目标项目有更严格的约束与检查命令，以项目落地的工具链为准（参考
-> `docs/tsl/toolchain.md`）。如果项目对自动化或 AI 代理有额外要求，应把约束直接写进仓库内可见的检查脚本、CI 配置或项目文档，而不是依赖隐藏规范。
+> 本节偏“实践建议”（should），用于提升可读性/可测试性；若目标项目有更严格的约束与检查命令，以项目脚本、CI 配置，或已填写且没有 `<...>` 占位符的
+> `docs/tsl/toolchain.md` 为准。如果项目对自动化或 AI 代理有额外要求，应把约束直接写进仓库内可见的检查脚本、CI 配置或项目文档，而不是依赖隐藏规范。
 
 ### 4.1 变量与常量