feat: add --fix flag for auto-fixing violations

[shinagawa-web]

Overview

Add a `--fix` flag that automatically repairs auto-fixable violations in Markdown files in-place.

Problem

gomarklint currently only detects and reports violations — users must fix them manually. Many violations follow deterministic patterns that can be repaired automatically (e.g., missing blank lines around fences, bare URLs, trailing punctuation in headings).

Design

Fix representation

Each `LintError` optionally carries a `Fix` describing how to repair the violation:

```go
type Fix struct {
StartLine int // first affected line (1-indexed)
EndLine int // last affected line (inclusive); == StartLine for single-line
Lines []string // replacement lines (nil = delete the range)
}
```

Rules that can produce a fix attach it to the `LintError` they return. Rules that cannot fix a violation leave `Fix` nil.

Application order

Fixes are applied from the bottom of the file upward (descending line order) so that insertions and deletions on earlier lines do not shift the line numbers of later fixes.

CLI

```
gomarklint --fix [files...]
```

Exits 0 when all violations were fixed (or there were none). Exits non-zero if any unfixable violations remain after applying fixes.

Idempotency

Running `--fix` twice must produce identical output.

Fixable rules

Rule	Fix
`final-blank-line`	Append a newline at end of file
`no-hard-tabs`	Replace `\t` with spaces
`no-bare-urls`	Wrap in angle brackets: ``
`no-setext-headings`	Convert setext heading to ATX (`#` / `##`)
`no-multiple-blank-lines`	Collapse consecutive blank lines to one
`blanks-around-fences`	Insert / delete blank lines around code fences
`blanks-around-headings`	Insert / delete blank lines around headings
`blanks-around-lists`	Insert / delete blank lines around lists
`no-trailing-punctuation`	Strip trailing punctuation from heading text
`consistent-code-fence`	Normalize all fences to the file's first style
`consistent-emphasis-style`	Normalize `*` / `_` to the file's first style
`consistent-list-marker`	Normalize `-` / `*` / `+` to the file's first style
`max-line-length`	Hard-wrap prose lines at word boundaries (skip code blocks and bare URLs)

Not auto-fixable

Rule	Reason
`single-h1`	Cannot decide which H1 to keep
`duplicate-heading`	Cannot decide which to rename
`empty-alt-text`	Cannot generate meaningful alt text
`no-empty-links`	Cannot supply a URL
`fenced-code-language`	Cannot guess the language
`external-link`	Cannot repair broken URLs
`link-fragments`	Cannot repair broken anchors
`heading-level`	Structural change — too risky to automate
`no-emphasis-as-heading`	Conversion is ambiguous (heading level unknown)
`unclosed-code-block`	Cannot determine where to close

Open questions

• Should `--fix` also print remaining (unfixable) violations, or stay silent on success?
• For `no-hard-tabs`: hard-code 4 spaces per tab, or add a config option?
• Add `--fix-dry-run` to preview changes without writing?

[shinagawa-web]

Implementation Plan

Files to create

• `internal/rule/fix.go` — `Fix` struct definition
• `internal/fixer/fixer.go` — fix application logic (reverse-order, write-back)
• `internal/fixer/fixer_test.go` — unit tests (single-line replace, insert, delete, ordering)

Files to modify

• `internal/rule/heading_level.go` — add `Fix *Fix` field to `LintError`
• `internal/rule/final_blank_line.go` — attach fix
• `internal/rule/no_hard_tabs.go` — attach fix
• `internal/rule/no_bare_urls.go` — attach fix
• `internal/rule/setext_headings.go` — attach fix
• `internal/rule/no_multiple_blank_lines.go` — attach fix
• `internal/rule/blanks_around_fences.go` — attach fix
• `internal/rule/blanks_around_headings.go` — attach fix
• `internal/rule/blanks_around_lists.go` — attach fix
• `internal/rule/no_trailing_punctuation.go` — attach fix
• `internal/rule/consistent_code_fence.go` — attach fix
• `internal/rule/consistent_emphasis_style.go` — attach fix
• `internal/rule/consistent_list_marker.go` — attach fix
• `internal/rule/max_line_length.go` — attach fix
• `internal/linter/linter.go` — thread fixes through `Result`
• `internal/app/app.go` — wire fix mode; apply fixer before writing output
• `cmd/root.go` — add `--fix` flag

Checklist

• Define `Fix` struct in `internal/rule/fix.go`
• Add `Fix *Fix` field to `LintError`
• Implement `internal/fixer/fixer.go`: sort fixes descending by line, apply replacements, write file
• Unit-test fixer: single-line replace, line insertion, line deletion, multi-fix ordering
• Attach fix to `final-blank-line`
• Attach fix to `no-hard-tabs`
• Attach fix to `no-bare-urls`
• Attach fix to `no-setext-headings`
• Attach fix to `no-multiple-blank-lines`
• Attach fix to `blanks-around-fences`
• Attach fix to `blanks-around-headings`
• Attach fix to `blanks-around-lists`
• Attach fix to `no-trailing-punctuation`
• Attach fix to `consistent-code-fence`
• Attach fix to `consistent-emphasis-style`
• Attach fix to `consistent-list-marker`
• Attach fix to `max-line-length`
• Add `--fix` flag to `cmd/root.go`
• Wire fix mode in `app.Run`
• Add e2e test for `--fix` (apply fix, re-lint, expect 0 violations)
• Run `make test-all`

[shinagawa-web]

Design note: line-based vs character-offset fixes

ESLint represents fixes as character offsets ([start, end] byte range + replacement string) rather than line numbers. This has two advantages worth considering:

1. Conflict detection is natural — overlapping range checks are trivial; conflicting fixes are simply dropped and retried on the next pass.
2. No line-shift problem — insertions/deletions on earlier lines don't invalidate later fix positions, so reverse-order application is unnecessary.

The current proposal (line-based Fix struct) is simpler to implement given that all rules already think in terms of line numbers, but the offset-based approach is more robust if fixes ever need to target sub-line ranges (e.g., replacing a specific URL within a line for no-bare-urls).

Decision point: line-based (simpler, fits current rule API) vs offset-based (more robust, aligns with ESLint's model).