Build item_action and item_delete v2 #314

Write tools from #309. Start from the descriptions measured in tests/Conderis.Tests/ToolSurface/V2Prototype.cs.

item_action

• number or ref, action, version, reason, target, relation.
• Task: claim, complete, block (reason required, kept in the history), unblock. Proposal: approve, reject, withdraw. Memory and page: archive, restore. Any item: relate, unrelate.
• version is checked for task, memory and page actions; relate, unrelate and the proposal actions need none.

item_delete

• Requests permanent deletion of an item or one version and locks it at once. version names the version to delete; without it the whole item.

Done (ed7fb7d)

src/Conderis/Services/Items/ItemActionTools.cs (not registered until #317), TaskService.Block, Unblock and BlockReason; tests in ItemActionToolsTests, and both tools in BuiltV2ToolsMatchTheMeasuredSchemas.

Decisions taken while building:

• Tasks are not archived. Nothing archives a task today; a task is completed or canceled. archive on a task is refused with that hint. The item_action description now says "memory and page: archive, restore" and that block, approve and reject need a reason (the server already required a review reason). The v2 list grew from 6,386 to 6,438 characters; #309's numbers are updated with the next measurement.
• Blocking stores the reason in the task history entry (reason next to the status change); item_get shows blockReason while a task is blocked; unblock restores the status recorded before the block (open if unknown).
• Proposals are decided without version: the tool reads the current state, refuses a decided proposal ("already approved"), and passes the stored version to the service, whose serializable transaction lets only one of two concurrent decisions commit (tested with two moderators).
• Capability messages: a key without moderate is refused before the proposal is read, naming the moderate permission; a person without moderator rights is refused naming moderator rights.
• Stable version numbers: numbering counts every published revision, including ones locked for privacy deletion, so deleting an old version leaves a gap instead of renumbering the later ones; reading a locked version says it is no longer readable.
• Deleting a task takes no version (a task is deleted whole); the tool passes the current version to the service.
• Stale versions are refused with the current version in the message, also for task actions whose service messages did not name it.

Web check for privacy_deletion_queue and privacy_deletion_review: the Moderation page lists the requests, confirms permanent deletion and rejects (content stays locked), which is everything the MCP tools offered. Neither side offers a reason on rejection or unlocking a wrongly locked item; that is no regression and not part of v2.

For #317: state in the system guide and on /connect that one tool now carries task work and moderation, so only the agent key's capabilities separate them.