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