[pournasserian]

Closes #2615

What

create_content_type and revise_content_type now answer from the change set their write joined, read by its id, instead of looking up the session's open set again after the write commits.

• IContentTypeDirectory gains CreateInChangeSetAsync and ReviseInChangeSetAsync. They do what CreateAsync and ReviseAsync do and return a ContentTypeWrite: the content type and the id of the set the write joined.
• ContentTypeDirectory sets that id once the write has committed. CreateAsync and ReviseAsync keep their shape and behaviour.
• ProposedWrite reads the set with IChangeSetDirectory.GetAsync(id).
  • A set submitted in the meantime still answers, with the write's operation and the set's new state.
  • Its next then says the set was submitted since, and that further changes go into a new set.
• ChangeSetTarget.ReadAsync, which only the tool used, is removed.
• The two admin test fakes of IContentTypeDirectory stub the new methods.

Why

Between the write and the second lookup, the agent could submit the set, or a concurrent write could open the session's next one. In the first case a committed write was answered with change_set_not_found, which invites a retry and a second draft. In the second, ProposedWrite didn't find the operation and threw.

Choices worth a look:

• New methods, not a changed return type: CreateAsync and ReviseAsync have many callers, mostly tests, that only need the type. The new methods are additive, and IContentTypeDirectory isn't an [ExtensionPoint].
• The id is set after the commit, so a write that rolls back or loses a conflict reports no set.
• A submitted set still answers successfully: the write is stored, so a failure would invite the retry this fixes.

Tests

SchemaWriteAnswerTests, each on SQLite and PostgreSQL, call the create_content_type tool through a directory that lets another call in right after the write commits:

• The set is submitted meanwhile. The answer has that set's id, state checks_running, version 1, and the "submitted since" text.
• The set is submitted and the session opens its next set meanwhile. The answer has the set the write joined, which is no longer the session's set, and doesn't throw.

The existing schema tool and write tool tests pass unchanged. The full suite ran locally against a postgres:17 container as well as SQLite. No new package and no new project reference.

Checklist

• Linked to an issue a maintainer has confirmed
• Targets v2
• Tests or docs updated where behaviour changed
• No tool-generated co-author trailers or footers