Add "Reopen with Encoding" feature (Local/Single user)

Summary

This PR adds a "Reopen with Encoding" feature to allow users to manually specify an encoding and reload the active buffer.

This feature allows users to explicitly specify the encoding and reload the file to resolve garbled text caused by incorrect detection.

Changes

1. Added encoding picker logic to encoding_selector

• Implemented a modal UI accessible via the command palette, shortcuts, or by clicking the encoding status in the status bar.
• Allows users to select from a list of supported encodings (Shift JIS, EUC-JP, UTF-16LE, etc.).

2. Updated Buffer logic (crates/language)

• Added a force_encoding_on_next_reload flag to the Buffer struct.
• Updated the reload method to check this flag and apply the following logic:
  • Non-Unicode (e.g., Shift JIS): Bypasses heuristics (like BOM checks) to force the specified encoding.
  • Unicode (e.g., UTF-8): Performs standard BOM detection. This ensures that the BOM is correctly handled/consumed when switching back to UTF-8.

3. UI / Keymap

• Made the encoding status in the status bar (ActiveBufferEncoding) clickable.
• Added default keybindings:
  • macOS: cmd-k n
  • Linux/Windows: ctrl-k n
  • Windows: ctrl-k n

Limitations & Scope

To ensure stability and keep the PR focused, the following scenarios are intentionally out of scope:

1. Collaboration and Remote Connections

• Encoding changes are disabled when collaboration (is_shared) or SSH remote connections (is_via_remote_server) are active.
• Reason: Synchronizing encoding state changes between host/guest or handling remote reloads involves complex synchronization logic. This PR focuses on local files only.

Remote Connection (SSH/WSL)

Via status bar	Via shortcut/command

Collaboration Session

Via status bar	Via shortcut/command

2. Dirty State

• The feature is disabled if the buffer has unsaved changes to prevent data loss during reload.

Via status bar	Via shortcut/command

3. Files detected as Binary

Files that worktree detects as "binary" (e.g., UTF-16 files without BOM containing non-ASCII characters) are not opened in the editor, so this feature cannot be triggered.
Future Work: Fixing this would require modifying crates/worktree heuristics or exposing a "Force Open as Text" action for InvalidItemView to trigger. Given the scope and impact, this is deferred to a future PR.

Test Plan

I verified the feature and BOM handling using the following scenarios:

Preparation

Used the following test files:

• test_utf8.txt: English-only text file. No BOM.
• test_utf8_bom.txt: English-only text file. With BOM.
• test_utf8_jp_bom.txt: UTF-8 with BOM file containing Japanese characters.
• test_shiftjis_jp.txt: Shift-JIS file containing Japanese characters (content designed to trigger misdetection, e.g., using only half-width katakana).

Used an external editor (VS Code or Notepad) for verification.

Case 1: English-only file behavior

1. Open an English-only UTF-8 file (test_utf8.txt).
2. Reopen as Shift JIS.
3. Result:

• Text appearance remains unchanged (since ASCII is compatible).
• Status bar updates to "Shift JIS".

Case 2: Fixing Mojibake

1. Open a Shift-JIS file (test_shiftjis_jp.txt) that causes detection failure.
   ※Confirm it opens with mojibake
2. Select Shift JIS from the status bar selector.
3. Result:

• Mojibake is resolved, and Japanese text is displayed correctly.
• Status bar updates to "Shift JIS".

Case 3: Unicode file with BOM behavior

1. Open an English-only UTF-8 with BOM file (test_utf8_bom.txt).
2. Reopen as Shift JIS.
3. Result:

• The BOM bytes are displayed as mojibake at the beginning of the file.
• The rest of the English text is displayed normally (ASCII compatibility).
• Status bar updates to "Shift JIS".

Case 4: Non-Unicode file with BOM behavior

1. Open a UTF-8 with BOM file containing Japanese (test_utf8_jp_bom.txt).
2. Reopen as Shift JIS.
3. Result:

• The BOM bytes at the start are displayed as mojibake.
• The Japanese text body is displayed as mojibake (UTF-8 bytes interpreted as Shift JIS).
• Status bar updates to "Shift JIS" (no BOM indicator).

Case 5: Revert to Unicode

1. From the state in Case 4 (Shift JIS with mojibake), reopen as UTF-8.
2. Result:

• The BOM mojibake at the start disappears (consumed).
• The text returns to normal.
• Status bar updates to "UTF-8 (BOM)".

Case 6: External BOM removal (State sync)

1. Open a UTF-8 with BOM file in Zed (test_utf8_bom.txt).
2. Open the same file in an external editor and save it as UTF-8 (No BOM).
3. Refocus Zed.
4. Result:

• Text appearance remains unchanged.
• The (BOM) indicator disappears from the status bar.
• Saving in Zed and checking externally confirms the BOM is gone.

Case 7: External BOM addition

1. From the state in Case 6 (UTF-8 No BOM), save as UTF-8 with BOM in the external editor.
2. Refocus Zed.
3. Result:

• The (BOM) indicator appears in the status bar.
• Saving in Zed and checking externally confirms the BOM is present.

Case 8: External Encoding Change (Auto-detect sync)

1. Open an English-only UTF-8 file in Zed (test_utf8.txt).
   • Status bar shows: "UTF-8".
2. Open the same file in an external editor and save it as UTF-16LE with BOM.
3. Refocus Zed.
4. Result:
   • The text remains readable (no mojibake).
   • Status bar automatically updates to "UTF-16LE (BOM)". (Verifies that buffer.encoding is correctly updated during reload).

Release Notes:

• Added "Reopen with Encoding" feature (currently supported for local files).