Decide: should "always" keep repository boundaries, or is the documented limit enough?

## Context

`respect-gitignore = "always"` is `WalkBuilder::require_git(false)`, and that
flag does two jobs: it decides whether `.gitignore` applies without Git
metadata, and it decides whether a repository marker bounds the search. Turning
it off for the first loses the second, so under `always` a repository below the
path being linted does not start a boundary of its own.

Under the default, `repository-only`, this does not arise.

## Observed behaviour

```console
$ printf 'lib/\n' > proj/.gitignore
$ mkdir -p proj/vendor/.git proj/vendor/lib
$ printf '#Hello.' > proj/vendor/lib/inner.md
$ cd proj && mado check .
```

| `respect-gitignore` | reports |
|---|---|
| `"repository-only"` | 3 errors |
| `"always"` | none |
| `git check-ignore lib/inner.md`, run in `vendor` | not ignored |

`proj/.gitignore` is outside the repository holding the file, so Git does not
apply it there. `always` does. #447 documents this as one of that mode's terms
and pins it in `tests/command_check.rs`.

## The decision to make

**Is the documented limit enough, or should `always` keep repository
boundaries?**

Keeping them needs the `ignore` crate to separate "require a repository before
applying `.gitignore`" from "stop at a repository marker while searching
upward". #436 tried to build that separation on top of the crate and could not:
`add_ignore` lands files in the lowest precedence slot, so the reconstruction
loses to what the walk finds for itself. The revision on #346 has the detail.

- *Leave it documented:* `always` is an explicit opt-in with stated terms, and
the default is unaffected.
- *Ask upstream:* propose the split as an `ignore` API change, and revisit this
when it exists.

## Related

- #346
- #447

Start with tests/command_check.rs and the terms documented in #447, then read #436 and the revision on #346 to understand why the ignore crate cannot currently separate the two behaviors. Done means choosing between leaving the limit documented and asking upstream for the API split, with that decision recorded; no implementation path is specified here.

由索引模型根据 Issue 内容生成。