fix(fe): stream bodies into blobs, and stop refusing legitimate bidi text

Two review points on `appMetadata.ts`.

The capped reader accumulated chunks into a `Uint8Array`, so a logo of
up to the cap was materialized as a JS buffer on its way to being
re-encoded. It now pipes the response through a counting transform into
a `Blob` instead: the bytes accumulate in the browser's blob store, only
one chunk at a time is a JS buffer, and the blob goes straight to
`createImageBitmap`, so the encoded image is never a JS value at all.
The cap still bounds the transfer rather than just the result -- erroring
the transform aborts the source stream. The metadata document still
becomes a string, since 8 KiB of JSON has to be parsed.

Refusing every bidi and zero-width character broke exactly the names
that need them. The marks U+200E/U+200F/U+061C are how an Arabic name
ending in "!" or a Hebrew name with an embedded Latin word gets its
neutral characters on the right side; the isolates U+2066-U+2069 are
Unicode's recommended way to embed a run of unknown direction; U+200B is
a line-break opportunity in Thai and Khmer. None of them can reorder
text, so all are now accepted. What is refused is the set that can: the
embeddings and overrides U+202A-U+202E (plus control characters and
U+FEFF as before). Isolates additionally have to be balanced, so an
app's string cannot run past itself into the sentence II renders around
it, and a field has to contain at least one visible character, so an
all-invisible name is treated as absent instead of displayed as a blank.
The app-provided description also renders with `dir="auto"` now, which
resolves its direction from its own content and isolates it from the
screen.

The published JSON Schema follows, and notes the one rule it cannot
express (isolate balance).

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ApQTUxtZxjzpFsoJqKCXxo

Author: claude

docs/ii-spec.mdx

@@ -357,7 +357,9 @@ Requirements:
 
 - All fields are optional, and unknown fields are ignored, so that fields added in the future do not invalidate documents for older versions of Internet Identity. A document that carries no field Internet Identity knows is ignored; a valid document replaces any curated fallback entry wholesale.
 - A field that is present but does not meet the requirements below invalidates **the whole document**, which is then ignored — the offending field is not simply dropped. An application whose file is wrong therefore sees none of its metadata applied, instead of shipping a file that is silently half-applied on a screen it does not control; Internet Identity also logs which field is at fault to the browser console.
-- `name` must not exceed 40 characters and `description` must not exceed 120 characters, counted in Unicode code points on the value as served. Neither may be blank, and neither may contain control characters (other than the ASCII whitespace characters `\t`, `\n`, `\v`, `\f` and `\r`) or zero-width and bidirectional formatting characters, which could otherwise make the rendered text read differently from what it contains. The zero-width joiners U+200C and U+200D are allowed, since they are needed for correct shaping in scripts such as Persian and for emoji sequences.
+- `name` must not exceed 40 characters and `description` must not exceed 120 characters, counted in Unicode code points on the value as served. Neither may contain control characters (other than the ASCII whitespace characters `\t`, `\n`, `\v`, `\f` and `\r`), the bidirectional embeddings and overrides U+202A–U+202E, or U+FEFF. Only these reordering controls are refused: an override makes text render in an order other than the one it is written in, which is what would let a name read as something it does not contain, and the embeddings are deprecated in favour of the isolates for the same reason.
+- The characters that mixed-direction and non-Latin names legitimately need are accepted: the bidirectional marks U+200E, U+200F and U+061C (zero-width hints that only affect where neutral characters such as punctuation and digits land at a direction boundary), the bidirectional isolates U+2066–U+2069, and the zero-width characters U+200B–U+200D (line-break opportunities in scripts such as Thai and Khmer, shaping in scripts such as Persian, and emoji sequences). Isolates must be **balanced**, however: a field must close every isolate it opens and close none it did not open, since an unbalanced isolate would extend past the application's own text and reorder what Internet Identity renders around it.
+- A field must contain at least one visible character — one that is neither whitespace nor one of the invisible characters above — so that a field which renders as nothing is treated as absent rather than displayed as a blank name.
 - Before being displayed, `name` and `description` have runs of whitespace collapsed to single spaces and are trimmed. This is presentation only, applied after the requirements above are checked: it never rescues a value that violates them.
 - `logo` must be a URL (relative URLs are resolved against the document's origin) pointing to a raster image _on that same origin_. It must be served with one of the content types `image/png`, `image/jpeg`, `image/webp`, `image/gif` or `image/avif`, must not exceed 1 MiB, and must decode to an image of at most 4096 pixels per axis. Internet Identity downloads the logo (it is never hotlinked), so both the metadata document and the logo asset must be readable cross-origin (see the CORS note below).
 - The logo is not rendered as served: Internet Identity decodes it, draws it once into a canvas scaled to at most 512 pixels on its longest side, and renders that re-encoding from a `blob:` URL. What is displayed is therefore an image Internet Identity produced itself — still (an animated image is flattened to its first frame), bounded in size, and held in the browser's blob store rather than in the page's DOM or its JavaScript heap. `image/svg+xml` is not accepted, because a vector image cannot be put through that step across the browsers Internet Identity supports; applications with a vector logo serve a rasterized copy of it here.
@@ -366,7 +368,7 @@ Requirements:
 
 ### JSON Schema {#app-metadata-schema}
 
-The schema below expresses the requirements above, so a document that validates against it is one Internet Identity accepts (whitespace normalization happens after validation and is not part of it). Validating in CI is the easiest way to catch a mistake before it costs the application its metadata.
+The schema below expresses the requirements above, with one exception it cannot state: that bidirectional isolates must be balanced. Whitespace normalization happens after validation and is not part of it either. Validating in CI is the easiest way to catch a mistake before it costs the application its metadata.
 
 ```json
 {
@@ -380,16 +382,16 @@ The schema below expresses the requirements above, so a document that validates
       "type": "string",
       "minLength": 1,
       "maxLength": 40,
-      "pattern": "\\S",
-      "not": { "pattern": "[\\u0000-\\u0008\\u000e-\\u001f\\u007f-\\u009f\\u061c\\u200b\\u200e\\u200f\\u202a-\\u202e\\u2066-\\u2069\\ufeff]" }
+      "pattern": "[^\\s\\u061c\\u200b-\\u200f\\u2066-\\u2069]",
+      "not": { "pattern": "[\\u0000-\\u0008\\u000e-\\u001f\\u007f-\\u009f\\u202a-\\u202e\\ufeff]" }
     },
     "description": {
       "description": "Short description or tagline of the application",
       "type": "string",
       "minLength": 1,
       "maxLength": 120,
-      "pattern": "\\S",
-      "not": { "pattern": "[\\u0000-\\u0008\\u000e-\\u001f\\u007f-\\u009f\\u061c\\u200b\\u200e\\u200f\\u202a-\\u202e\\u2066-\\u2069\\ufeff]" }
+      "pattern": "[^\\s\\u061c\\u200b-\\u200f\\u2066-\\u2069]",
+      "not": { "pattern": "[\\u0000-\\u0008\\u000e-\\u001f\\u007f-\\u009f\\u202a-\\u202e\\ufeff]" }
     },
     "logo": {
       "description": "URL of the raster application logo, on the same origin as this document",

src/frontend/src/lib/components/ui/AuthorizeHeader.svelte

@@ -74,7 +74,11 @@
       <Ellipsis text={hostname} position="middle" />
     </Badge>
     {#if metadata.description !== undefined}
+      <!-- `dir="auto"` resolves the direction from the text itself and isolates
+           it from the rest of the screen, so an RTL description reads correctly
+           and can't reorder anything around it. -->
       <p
+        dir="auto"
         class="text-text-tertiary line-clamp-2 max-w-[85%] text-center text-sm text-balance"
       >
         {metadata.description}

src/frontend/src/lib/utils/appMetadata.test.ts

@@ -322,21 +322,6 @@ test("should reject the whole document when a field has the wrong type", async (
   }
 });
 
-test("should reject the whole document when a text field is blank", async () => {
-  for (const body of [
-    { name: "", description: "An example app" },
-    { name: "   ", description: "An example app" },
-    { name: "Example App", description: "\t\n" },
-  ]) {
-    setupFetchMock(Response.json(body));
-
-    expect(
-      await fetchAppMetadata(ORIGIN),
-      JSON.stringify(body),
-    ).toBeUndefined();
-  }
-});
-
 test("should name the offending field when rejecting a document", async () => {
   // The console warning is the only signal an app's developers get, so it has
   // to say which field is at fault.
@@ -368,19 +353,19 @@ test("should normalize whitespace in text fields", async () => {
   });
 });
 
-test("should reject documents whose text fields carry control or bidi characters", async () => {
-  // These can visually reorder or hide parts of a name on the sign-in screen.
-  // Rejecting is both safer than stripping and visible to the app: a name that
-  // renders as something else than it reads is a bug in the file.
+test("should reject documents whose text fields carry reordering controls", async () => {
+  // Control characters, and the bidi embeddings and overrides: the latter make
+  // text render in an order other than the one it is written in, which is how a
+  // name could read as something it doesn't contain.
   for (const char of [
     "\u0000", // NUL
     "\u0007", // BEL
     "\u001b", // ESC
-    "\u061c", // arabic letter mark
-    "\u200b", // zero-width space
-    "\u200f", // right-to-left mark
+    "\u202a", // left-to-right embedding
+    "\u202b", // right-to-left embedding
+    "\u202c", // pop directional formatting
+    "\u202d", // left-to-right override
     "\u202e", // right-to-left override
-    "\u2066", // left-to-right isolate
     "\ufeff", // zero-width no-break space
   ]) {
     setupFetchMock(
@@ -394,6 +379,59 @@ test("should reject documents whose text fields carry control or bidi characters
   }
 });
 
+test("should accept the bidi characters mixed-direction names need", async () => {
+  // These only hint at where neutral characters land, or isolate a run; none of
+  // them can reorder text. Refusing them would break exactly the names that
+  // need them: RTL text with an embedded Latin word, or ending in punctuation
+  // whose side would otherwise follow the paragraph direction.
+  for (const name of [
+    `\u200fשלום Example!`, // RTL mark
+    `Example \u200eעברית`, // LTR mark
+    `\u061cالعربية Example`, // arabic letter mark
+    `\u2068Example\u2069 في المتجر`, // first-strong isolate, balanced
+    `\u2066Example\u2069 و\u2067עברית\u2069`, // nested, balanced
+    `ราคา\u200bถูก`, // zero-width space as a Thai line-break opportunity
+  ]) {
+    setupFetchMock(Response.json({ name }));
+
+    expect(await fetchAppMetadata(ORIGIN), name).toEqual({ name });
+  }
+});
+
+test("should reject unbalanced bidi isolates", async () => {
+  // An isolate only contains its contents while it is closed. Left open, it
+  // runs to the end of the paragraph -- past the app's own name and into the
+  // sentence II renders around it.
+  for (const name of [
+    `Example\u2066`, // opened, never closed
+    `\u2069Example`, // closed without being opened
+    `\u2066Example\u2069\u2069`, // one close too many
+    `\u2068\u2067Example\u2069`, // one close too few
+  ]) {
+    setupFetchMock(Response.json({ name, description: "An example" }));
+
+    expect(await fetchAppMetadata(ORIGIN), name).toBeUndefined();
+  }
+});
+
+test("should reject text fields with nothing visible in them", async () => {
+  // Whitespace, bidi marks, isolate controls and zero-width characters all
+  // render as nothing, so a field made only of those is an absent field.
+  for (const name of [
+    "   ",
+    "\u200b\u200b",
+    "\u200e\u200f",
+    ` \u2066\u2069 `,
+  ]) {
+    setupFetchMock(Response.json({ name, description: "An example" }));
+
+    expect(
+      await fetchAppMetadata(ORIGIN),
+      JSON.stringify(name),
+    ).toBeUndefined();
+  }
+});
+
 test("should preserve the zero-width joiners scripts and emoji need", async () => {
   // ZWNJ (U+200C) drives correct shaping in scripts such as Persian, and ZWJ
   // (U+200D) holds emoji sequences together. Neither is a control or bidi