Say outright whether the profile is ours to change

Whether to offer the profile settings was inferred from whether the host
could close Element Call. For a component with no host bridge — the
default — nothing could, so an embedded Element Call let the user edit
the profile of an account that belongs to the host application.

`HostBridge.supportsProfileChanges` states it directly: true standalone,
where Element Call signed the user in itself; false for a widget's host
and for anything embedding the component (which sets it itself, since
the client it hands over is its own). The profile tab and the profile
shortcut follow that. What a host's ability to close us still decides —
what to show after the call ends — is a question about who owns our
lifetime, and stays keyed on `close`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

src/HostBridge.test.ts

@@ -247,6 +247,11 @@ describe("createWidgetHostBridge", () => {
     });
   });
 
+  test("does not offer profile changes, since the host signed the user in", () => {
+    const bridge = createWidgetHostBridge(mockWidget({}));
+    expect(bridge.supportsProfileChanges).toBe(false);
+  });
+
   describe("supportsReactions", () => {
     const capabilities = [
       "org.matrix.msc2762.send.event:m.reaction",
@@ -278,6 +283,10 @@ describe("nullHostBridge", () => {
     expect(nullHostBridge.close).toBeUndefined();
   });
 
+  test("supports profile changes, since Element Call signed the user in itself", () => {
+    expect(nullHostBridge.supportsProfileChanges).toBe(true);
+  });
+
   test("offers no media download, so Element Call uses its own client", () => {
     expect(nullHostBridge.downloadMedia).toBeUndefined();
   });