Share files and folders with other people

Calendars and address books have been shareable since JMAP Sharing went
in; Files never was, though Stalwart treats file storage as a first-class
thing to share and ihasmail has carried the types for it all along.
`FilesRights` and `FileNode.shareWith` were already declared -- what was
missing was asking for the property, offering the dialog, and saying so
in the list.

Checked against the live 0.16.19 first, read-only, because building a
picker against a mock that agrees with you proves nothing:

  - `FileNode/get` returns `shareWith`, and `myRights` carries all six
    rights, `mayShare` among them and true on one's own nodes. So the
    menu entry has a real right to gate on -- unlike folder sharing,
    which is offered ungated because `MailboxRights` has no such right
  - `Principal/query` answers now that `allowDirectoryQueries` is on:
    six individuals, no groups
  - `ShareNotification/get` is implemented, which is worth knowing for
    later; nothing here reads it yet

The editor preset grants read, add files and edit contents, and stops
there. Rename and delete stay with whoever shared the folder: someone
given a folder to work in should not be able to rename the thing they
were given, or delete it out from under the person who shared it. Both
are still there to tick by hand.

One finding is worth a test of its own, and has one. Stalwart answers
`shareWith` as `{}` for a node shared with nobody, not `null` -- every
unshared node in a live account came back that way. A truthiness test on
the property is therefore true for every node the server has ever
returned, and the badge driven by it would report the whole account as
shared while being, technically, about the right property. `isShared`
counts keys, and the test says why.

Verified against the mock end to end: sharing Documents with a principal
as Editor persists `mayRead`, `mayAddChildren` and `mayModifyContent` and
nothing else, the badge appears on that folder and not on the file beside
it, and re-opening the dialog shows the saved rights rather than an empty
form -- which is what proves `fileNodeProps` is really asking for the
property.

web/src/store/files.ts

@@ -21,6 +21,7 @@ interface FilesState {
   rename(id: Id, name: string): Promise<void>;
   move(id: Id, parentId: Id | null): Promise<void>;
   destroy(ids: Id[]): Promise<void>;
+  refresh(ids: Id[]): Promise<void>;
   pathTo(id: Id | null): FileNode[];
   applyChanges(types: Set<string>): void;
 }
@@ -129,6 +130,20 @@ export const useFiles = create<FilesState>((set, get) => ({
     await get().loadChildren(parentId);
   },
 
+  /* Re-read named nodes in place. Sharing changes one property of one node and
+     nothing about which folder it sits in, so reloading the level around it
+     would be a bigger round trip to land in the same place. */
+  async refresh(ids) {
+    const accountId = get().accountId;
+    if (!accountId || !ids.length) return;
+    const res = await client.call<GetResponse<FileNode>>("FileNode/get", { accountId, ids, properties: fileNodeProps() });
+    set((s) => {
+      const nodes = { ...s.nodes };
+      for (const n of res.list) nodes[n.id] = n;
+      return { nodes };
+    });
+  },
+
   async rename(id, name) {
     const accountId = get().accountId!;
     const res = await client.call<SetResponse>("FileNode/set", { accountId, update: { [id]: { name } } });