docs(mkdir): the --verbose example showed output that never occurs - #19023

…9024)

## Description

`view source` renders a rest parameter without a space after the colon,
unlike
every other parameter kind:

```nu
> def test [a?:any --b:int ...rest:string] { echo 'test' }; view source test
def test [ a?: any --b: int ...rest:string] { echo 'test' }
```

`a?: any` and `--b: int` are spaced; `...rest:string` is not. In
`render_def`
the branches are:

| kind | format |
| --- | --- |
| required positional | `"{}: {} "` |
| optional positional | `"{}?: {} "` |
| flag with an argument | `": {arg}"` |
| rest | `"...{}:{}"` |

The rest branch is the only one missing the space. The command's own
examples
already show `...rest: string`, in two of them, so the documented form
was the
right one and the code disagreed with it.

Why it was not caught: `view_source.rs` declares eight example results
and had
no test running them. Adding `test_examples` for `ViewSource` is what
surfaced
this, and it also caught a second, smaller mismatch — the module example
claimed

```
" export-env { $env.FOO_ENV = 'BAZ' }"
```

while `view source` returns the source between the module's braces
verbatim,
so the real value has the trailing space too. That one is the example
being
wrong rather than the code, so the example is corrected.

## User-facing changes (Release notes)

`view source` now renders a rest parameter as `...rest: string` rather
than
`...rest:string`, matching how it already renders every other parameter.

## Tests + Formatting

Added `test_examples` for `ViewSource`, which runs all eight declared
example
results. It is not vacuous — it is what found both mismatches, failing
first on

```
expected: "def --env --wrapped foo [ ...rest: string] { print $rest }"
got:      "def --env --wrapped foo [ ...rest:string] { print $rest }"
```

and then on the module example. Both are green now.

The full `nu-command` lib suite (815 tests) and the existing
`view_source`
integration tests pass. I checked nothing asserted the old spelling: the
only
other `...name:type` in the tree is input source in an unrelated parser
test,
not an assertion on `view source` output. `cargo fmt --all -- --check`
and
`cargo clippy --all-targets` are clean.

## Additional notes

Third small `nu-command` fix from me after #19017 and #19023, same
theme: a
declared example result that nothing was checking.

Co-authored-by: Prajwal Narayana <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>