Bump `dandischema` pin once the `dandi-cli` release deadlock is broken

## Summary

[`dandischema` 0.13.0](https://github.com/dandi/dandi-schema/releases/tag/0.13.0) is out and raises `DANDI_SCHEMA_VERSION` from `0.7.0` to `0.8.0` (via https://github.com/dandi/dandi-schema/pull/419). We want to move our pin forward, but we cannot yet: `dandi-archive` and `dandi-cli` are deadlocked, and neither can be released first. This issue records the plan to break that deadlock. The examples below use 0.13.0 because it is the current release, but by the time we act the target will be whatever `dandischema` release is current then.

Current state in `pyproject.toml`:

- `dandischema==0.12.1` (schema version `0.7.0`)
- `dandi[extras]==0.74.3` in the `cli` extra

## Why neither side can go first

**`dandi-archive` cannot bump `dandischema` first.** The `cli` extra pins `dandi[extras]==0.74.3`, which requires `dandischema>=0.12.0,<0.13.dev0`, so the resolution fails outright. This is not just a stale pin: the latest `dandi` on PyPI (0.76.8) and `dandi-cli` `master` both still declare `dandischema ~= 0.12.0`.

uv lock failure after bumping the pin to 0.13.0

```
× No solution found when resolving dependencies for split (markers:
│ python_full_version >= '3.15' and platform_machine != 'arm64' and
│ sys_platform == 'darwin'):
╰─▶ Because dandi==0.74.3 depends on dandischema>=0.12.0,<0.13.dev0 and
dandiapi[cli] depends on dandi[extras]==0.74.3, we can conclude that
dandiapi[cli] depends on dandischema>=0.12.0,<0.13.dev0.
And because your project depends on dandischema==0.13.0 and your project
requires dandiapi[cli], we can conclude that your project's requirements
are unsatisfiable.
```

**`dandi-cli` cannot bump `dandischema` first either.** A client whose `DANDI_SCHEMA_VERSION` is newer than the server's refuses to talk to that server, so releasing a `dandi-cli` built against `dandischema` 0.13.0 would break it against every currently deployed `dandi-archive` instance. This is visible in https://github.com/dandi/dandi-schema/actions/runs/30847516620, where both `dandi-cli` test jobs (the `release` and `master` legs) fail with `SchemaVersionError` (494 occurrences in the log).

Representative failure from that run

```
elif (
server_ver.major == 0 and server_ver.release[:2] != our_ver.release[:2]
) or (
server_ver.major != our_ver.major
): # MAJOR, MINOR within 0.x.y and MAJOR within 1.x.y
> raise SchemaVersionError(
f"Server uses older incompatible schema version {server_schema_version};"
f" client supports {schema_version}."
E dandi.exceptions.SchemaVersionError: Server uses older incompatible schema version 0.7.0; client supports 0.8.0.

.../site-packages/dandi/dandiapi.py:745: SchemaVersionError
```

Job totals: `25 failed, 759 passed, 1 skipped, 3 xfailed, 8 xpassed, 21 warnings, 222 errors`.

## Plan

https://github.com/dandi/dandi-schema/pull/342 ("Add ability to downgrade schema all the way to 0.6.10", motivation in https://github.com/dandi/dandi-schema/issues/343) lets `dandi-cli` interact with a `dandi-archive` instance running an older `DANDI_SCHEMA_VERSION`, which breaks the deadlock. So:

1. Wait for https://github.com/dandi/dandi-schema/pull/342 to be merged and released.
2. Wait for `dandi-cli` to release a version pinning `dandischema` to that new release.
3. In this repo, bump both pins together: `dandischema` in `dependencies`, and `dandi[extras]` in the `cli` extra. Update the trailing `# schema version` comment and regenerate `uv.lock`.

Steps 1 and 2 are external; this issue tracks step 3.