Clarify Behavior When Inviting Non-Existent Users

Nobody has claimed this yet.

### Description:
Currently, the Matrix specification does not explicitly define the expected behavior when a user attempts to invite a user ID that does not yet exist on the homeserver.

For example, in Synapse, if an invite is sent to a non-existent user ID (e.g., `@nonexistent:example.com`), the server responds with `200 OK`, and if an account is later registered with that user ID, the invite becomes active and the user is automatically added to the room.

It is unclear from the specification whether this is the intended or recommended behavior, or whether servers should reject invites to unknown user IDs at the time of the invite.

### Steps to Reproduce (Example in Synapse):

1. Invite a non-existent user ID:
```
/invite @nonexistent:example.com
```
2. Observe that the server responds with `200 OK`.
3. Later, register a user with `@nonexistent:example.com`.
4. The user automatically enters an invited membership state for the room upon registration, without explicit consent or action from the user.

### Expected Behavior:

- The specification should clarify whether inviting a non-existent user ID is allowed.
- If not allowed, the server should return an error (with an error code and message) indicating that the user ID does not exist at the time of the invite.
- If allowed, it should be explicitly documented that the invite will remain pending until such a user is registered.

### Actual Behavior (Example in Synapse):

- The server returns `200 OK` even though the user ID does not exist.
- If a user registers later with that ID, they are automatically invited into the room.

### Additional Context:

This behavior may cause confusion for clients and users, since an invite appears successful even if the user does not exist at the time. It may also have implications for security and invitation semantics.

### Proposed Solution:

- Clarify in the specification whether inviting a non-existent user is valid.
- If not valid, require servers to return an appropriate error code and message in a machine-readable format (e.g., JSON).
- If valid, define explicitly what happens to such an invite, how long it remains pending, and how clients should handle it.

Review the Matrix specification sections covering invitations, user registration, membership states, and relevant error responses. Determine whether inviting a non-existent user is valid and define the expected pending-invite behavior, expiration, consent, and client handling. Done means the specification records one unambiguous behavior and its machine-readable response requirements.

Written by the indexing model from the issue text.