Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="tools/i18n/sync_ocr_expected.py" line_range="423-432" />
<code_context>
+    unresolved_texts: List[str] = []
+
+    # 第一轮：唯一命中
+    for text, candidates in candidates_by_text:
+        if len(candidates) == 1:
+            lang_id = next(iter(candidates))
+            if lang_id not in resolved_set:
+                resolved_in_order.append(lang_id)
+                resolved_set.add(lang_id)
+        elif len(candidates) == 0:
+            unresolved_texts.append(text)
+
+    # 第二轮：如果歧义候选与已解析 ID 有交集，用交集兜底
+    for text, candidates in candidates_by_text:
+        if len(candidates) > 1:
+            intersection = [lang_id for lang_id in resolved_in_order if lang_id in candidates]
+            if len(intersection) == 1:
+                lang_id = intersection[0]
+                if lang_id not in resolved_set:
</code_context>
<issue_to_address>
**issue (bug_risk):** Ambiguous text resolution logic can never assign an ID from the intersection because of the `resolved_set` check.

In the second pass, `intersection` is derived from `resolved_in_order`, and `resolved_set` is built from the same list. That makes the `if lang_id not in resolved_set` guard always false for any `lang_id` in `intersection`, so the body never runs and ambiguous texts are never resolved via this heuristic. If you want ambiguous texts to reuse an existing ID, you likely need to (a) drop this guard and avoid re-adding to `resolved_in_order`/`resolved_set`, or (b) allow duplicate entries in `resolved_in_order`. As written, the second-pass logic is effectively dead code.
</issue_to_address>

### Comment 2
<location path="tools/i18n/sync_ocr_expected.py" line_range="472-481" />
<code_context>
+    unresolved_all: List[Tuple[str, str, List[str]]] = []
+
+    for file_path in pipeline_files:
+        try:
+            new_text, changes, unresolved_nodes, ocr_nodes = process_pipeline_file(
+                file_path, tables, reverse_index
+            )
+        except Exception as exc:
+            safe_print(f"[ERROR] {file_path}: {exc}")
+            continue
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Swallowing all exceptions when processing files can hide broken JSON or logic errors while still returning exit code 0.

Because the loop only logs and continues on `Exception`, CI will show success even when some files fail to parse or process, leading to silently partial updates. Consider tracking failures (e.g., a `failed_files` counter) and exiting non‑zero from `main()` if any occur, or selectively re‑raising for critical exceptions like JSON/parse errors so the job fails visibly.

Suggested implementation:

```python
    unresolved_all: List[Tuple[str, str, List[str]]] = []
    failed_files: List[Tuple[str, Exception]] = []

    for file_path in pipeline_files:
        try:
            new_text, changes, unresolved_nodes, ocr_nodes = process_pipeline_file(
                file_path, tables, reverse_index
            )
        except Exception as exc:
            safe_print(f"[ERROR] {file_path}: {exc}")
            failed_files.append((file_path, exc))
            continue

    if failed_files:
        safe_print(
            f"[ERROR] 共有 {len(failed_files)} 个文件处理失败，退出码为 1："  # summary in Chinese to match existing comments
        )
        for path, exc in failed_files:
            safe_print(f"  - {path}: {exc}")
        # 非零退出码以便 CI 正确失败
        sys.exit(1)

```

1. Ensure `sys` is imported at the top of `tools/i18n/sync_ocr_expected.py`:

   - Add `import sys` alongside the other imports if it's not already present.

2. The shown snippet is likely inside `main()` or another top‑level function. If this loop is not in `main()`, make sure that the `sys.exit(1)` (or equivalent non‑zero exit) is ultimately called from `main()` after this function returns a status indicating failure, instead of exiting directly from deep inside the call stack. Adjust the control flow accordingly if needed.
</issue_to_address>