fix: auto-fix linting issues - #70

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@CLAUDE-CODE-PARITY.md`:
- Around line 231-239: Remove the “Message Sequence Validator” item from the
pending list in the roadmap document, since the validation logic already exists
in src/core/message-validator.ts via autoCorrectMessageSequence. Update the list
so it reflects the current codebase and does not present validateMessageSequence
as an unresolved gap.

In `@src/core/config.ts`:
- Around line 132-142: The `config-init` flow in `access(CONFIG_PATH)` is
swallowing every error except the “Config already exists” case, which hides real
failures when `--force` is false. Update the `try/catch` in `src/core/config.ts`
so the `createConfig`/config-init check only ignores the `ENOENT` case from
`access()`, and rethrow any other `Error` instead of treating it as “file
missing.”

In `@src/core/message-validator.ts`:
- Around line 59-74: The tool call registration in message-validator’s
assistant-only rule is too permissive because non-assistant messages with
tool_calls are ignored instead of rejected. Update the validation logic around
the existing msg.role === 'assistant' && msg.tool_calls block to explicitly fail
when any message with tool_calls has a role other than assistant, using
MessageValidationError with the offending msg and index. Keep the duplicate ID
check and pendingToolCalls registration in place for valid assistant tool calls.
- Around line 144-149: The isMessageSequenceValid helper is swallowing
validation failures by catching without exposing the error, which hides the
cause of invalid sequences. Update the catch in isMessageSequenceValid to
capture the thrown error from validateMessageSequence and emit a meaningful
message through the existing error handling path before returning false, so the
failure reason is preserved for debugging.

In `@src/tools/search-text.ts`:
- Line 66: The search-text tool currently swallows read failures in the catch
block and can return a clean “No matches found” even when the scan was partial.
Update the logic in search-text.ts around the file-reading loop and the catch in
the search flow to track how many candidate files were skipped or unreadable,
then surface that in the result message or throw a meaningful error if every
readFile attempt failed. Use the existing searchText/search loop and readFile
handling to keep the partial-result signal visible to callers.

In `@src/utils/autocomplete.ts`:
- Line 1: The autocomplete entry classification in autocomplete.ts is treating
symlinks as regular files because entry.isDirectory() only reflects the link
itself, so linked directories lose the trailing slash and cannot be traversed.
Update the logic around the directory-entry handling in the autocomplete flow to
resolve or stat the symlink target before deciding whether to append "/" and
recurse, using the existing autocomplete-related symbols to locate the
classification branch.

In `@src/utils/storage-limit.ts`:
- Line 43: No silencien los errores en los flujos de escaneo y limpieza de
disco: los bloques catch alrededor de `readdirSync`, `statSync` y `unlinkSync`
están ocultando fallos y devolviendo tamaños parciales o limpiezas aparentemente
exitosas. Ajusten `checkStorageLimit()` y `enforceStorageLimit()` para capturar
el error real, registrarlo o relanzarlo con contexto útil, y evitar decisiones
basadas en resultados incompletos; si hay helpers internos en
`storage-limit.ts`, aseguren que también propaguen el detalle del fallo en lugar
de absorberlo.

---

Outside diff comments:
In `@src/core/agent.ts`:
- Around line 649-656: The catch block in agent.ts re-parses
toolCall.function.arguments while handling an error, which can throw the same
exception again and prevent the role:'tool' fallback from being added. Update
the error path in the tool execution handler so it reuses the already-available
arguments value instead of calling JSON.parse inside the catch, and keep the
recovery flow in the same try/catch around the tool invocation.

In `@src/core/config.ts`:
- Around line 59-65: The config loading fallback in the `readFile`/`deepMerge`
blocks is treating all failures like a missing file, which hides corrupt JSON or
permission errors. Update the `catch` logic in `src/core/config.ts` so the
defaults fallback is only used for `ENOENT`, and for any other error rethrow
with meaningful context about whether it came from the global config or the
local project config. Apply the same handling pattern to both config-loading
sections so `CONFIG_PATH` and the local config path behave consistently.

---

Nitpick comments:
In `@CRITICAL-FIXES.md`:
- Around line 7-9: The “Pre-commit hook: ACTIVE ✅” note is overstating a
local-only hook as enforced; update the wording in CRITICAL-FIXES.md to describe
it as a local `.git/hooks/pre-commit` configuration unless the hook is actually
versioned or run in CI. If the intent is repository-wide enforcement, move the
check into a tracked script or CI step and reference that instead; otherwise,
make the status explicitly local in the relevant section.