fix: merge per-path Codex filesystem rules across read/edit/write categories

[dyoshikawa]

Summary

Codex CLI models a single filesystem access level per path (deny < read < write), while rulesync's canonical model has separate read/edit/write categories. convertRulesyncToCodexProfile iterated the categories independently and wrote each rule with a plain assignment, so when the same pattern appeared in multiple categories the last-processed category silently overwrote the earlier one — read: allow + write: deny emitted "{path}" = "deny", blocking reads the user explicitly allowed, when the intended "readable but not writable" is exactly what Codex's "read" level expresses.

Changes

• New mergeFilesystemCategoryRules collects the three categories and emits one access level per pattern, order-independently:
  • edit/write collapse onto Codex's write side; when both carry the same pattern, the more restrictive action wins (deny > ask > allow).
  • read: allow + write-side allow → "write"
  • read: allow + write-side non-allow → "read" (the issue's headline case)
  • read non-allow → "deny"; a contradictory write-side allow ("writable but not readable" is not expressible in Codex) emits a warning.
  • Single-category patterns keep the existing mapReadAction/mapWriteAction mappings — no behavior change for configs without cross-category overlaps.
• Round-trip asymmetry documented (issue step 4): "{path}" = "read" imports back as read: allow only; the write-side deny is implied by Codex's access level and deliberately not re-materialized (synthesizing write: deny on import would pollute round-trips of plain single-category read rules). Recorded in the merge function's doc comment.
• Unit tests cover the merge matrix (read+write allow/deny combinations, contradiction warning, edit-vs-write restrictive collapse).

Closes #2283

🤖 Generated with Claude Code

[dyoshikawa]

@dyoshikawa Thank you!