Validate `[provides.instance]` per RFC 0049

[Maximilian-Nesslauer]

RFC 0049 (content-manager-design#49) adds [provides.instance] to a mod-loader listing, with flag and variable, so a manager learns from the listing how the loader is told which instance to run.

Where this stands today

schemas/authored.schema.json closes provides with additionalProperties: false.
A listing that carries the table is rejected by the schema check, so the StarMap listing cannot take the two lines the RFC gives it until the schema knows them.

What it should be instead

Today	Should be
provides accepts launch, content-dir, content-path and configure, and nothing else.	instance is a fifth member: an object with flag and variable, both strings, both non-empty and without whitespace, at least one of them present, no other keys.
schemas/README.md lists the rules the schema enforces per table.	It gains the rows for the new table: at least one key, single tokens, closed table.
test_check_schema.py covers the provides tables that exist.	It covers the new one: both keys, one key, neither key (reject), a key with whitespace (reject), an unknown key (reject), and the table on a mod listing (reject, through the existing provides rule).

Nothing else changes.
[provides] is never stamped into a release file (RFC 0035), so stamp_release.py and the release checks stay as they are, and the snapshot builder copies the authored document verbatim.

Tests

The schema tests above, run through validate.py the way the pull request checks run them.

Not in scope

The StarMap listing edit, which is its own issue, and the examples/ sync in the design repo.

Depends on

content-manager-design#49 accepted.
Until then this issue waits, and the schema must not accept a table the format does not define yet.