feat(api-client): add UserSearchClient for /api/user-search

Adds the client-side half of the user-search endpoint landed
on the server in b3056f1c (commit 6 on this branch). The
client mirrors the server's filter contract:

- query: substring match on FullName or UserName
- email: exact match on Email
- take: 1..100, default 25

Empty (query + email) short-circuits to an empty list
client-side rather than letting the server return the first
`take` users alphabetically — the address-book UX is
"type to search", not "show me a directory".

The DTO (Yavsc.Api.Client.Dtos.UserSearchResultDto) is a flat
shape (Id, UserName, FullName, Avatar, Email) with no
navigation properties; field names match the JSON the server
emits so deserialisation is a no-op.

PostIt wiring:
- App.axaml.cs constructs a UserSearchClient singleton and
  registers it alongside CircleApiClient and BlogAclApiClient.
- The PostIt.csproj ProjectReference to Yavsc.Api.Client was
  in place before this commit on feat/postit-acl; the rebase
  of feat/app-invite on top of feat/postit-acl dropped it.
  This commit re-adds it.

src/Yavsc.Api.Client/Dtos/UserSearchResultDto.cs

@@ -0,0 +1,23 @@
+namespace Yavsc.Api.Client.Dtos;
+
+/// <summary>
+/// Wire format for <c>GET /api/user-search</c>.
+///
+/// <para>Mirrors the server-side
+/// <c>Yavsc.Blogs.Controllers.UserSearchResultDto</c> but stops
+/// short of any entity navigation properties. Only the fields
+/// a client address book needs (id, name, avatar, email) are
+/// included.</para>
+///
+/// <para>Field names match the JSON the server emits (camelCase
+/// via the default <see cref="System.Text.Json"/> policy), so
+/// no <c>[JsonPropertyName]</c> attributes are required.</para>
+/// </summary>
+public sealed class UserSearchResultDto
+{
+    public string Id { get; set; } = string.Empty;
+    public string UserName { get; set; } = string.Empty;
+    public string? FullName { get; set; }
+    public string? Avatar { get; set; }
+    public string? Email { get; set; }
+}