added voiceEnabled option to sendConversationEvent in Brand Concierge component

[MasonPinZ]

Description

• Adds a voiceEnabled boolean option to the sendConversationEvent command, allowing callers to route requests to the voice subpath (/brand-concierge-voice) on a per-call basis.
• When voiceEnabled is false (default), requests continue to use the existing /brand-concierge subpath — fully backwards compatible.
• Validation added in validateMessage.js for both message-based and data-based option shapes.

Usage example

// Routes to /brand-concierge-voice
alloy("sendConversationEvent", {
  message: { ... },
  voiceEnabled: true,
  onStreamResponse(fragment) {
    console.log(fragment);
  },
});

Related Issue

BRANDCON-3982

Motivation and Context

Screenshots (if appropriate):

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.
• I have added a Changeset (pnpm changeset) or it is not necessary because this PR is not consumer-facing.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4f91ca4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@adobe/alloy	Patch
@adobe/alloy-sandbox-browser	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[MasonPinZ]

@carterworks , @ninaceban , this is the new PR of adding voiceEnabled flag to Brand Concierge. Can you please review it?

[carterworks]

Both of these tests are better written with async/await instead of flushPromiseChains()

  it("passes voiceEnabled from options to the service request", async () => {
    const mockResponse = {
      ok: true,
      status: 200,
      body: createMockReadableStream([]),
    };
    mockDependencies.sendConversationServiceRequest.mockResolvedValue(
      mockResponse,
    );

    const sendConversationEvent = createSendConversationEvent(mockDependencies);
    await sendConversationEvent({
      message: "Hello",
      onStreamResponse: vi.fn(),
      voiceEnabled: true,
    });

    expect(mockDependencies.buildEndpointUrl).toHaveBeenCalledTimes(1);

    const [{ request }] = mockDependencies.buildEndpointUrl.mock.calls[0];
    expect(request.getEdgeSubPath()).toBe("/brand-concierge-voice");
  });

  it("defaults to text subpath when voiceEnabled is not provided", async () => {
    const mockResponse = {
      ok: true,
      status: 200,
      body: createMockReadableStream([]),
    };
    mockDependencies.sendConversationServiceRequest.mockResolvedValue(
      mockResponse,
    );

    const sendConversationEvent = createSendConversationEvent(mockDependencies);
    await sendConversationEvent({
      message: "Hello",
      onStreamResponse: vi.fn(),
    });

    expect(mockDependencies.buildEndpointUrl).toHaveBeenCalledTimes(1);

    const [{ request }] = mockDependencies.buildEndpointUrl.mock.calls[0];
    expect(request.getEdgeSubPath()).toBe("/brand-concierge");
  });

[carterworks]

As-is, this version gets past your validation

validateMessage({ {
        xdm: {
          interactionId: "test-interaction-id",
        },
        voiceEnabled: "yes",
      } 
});

What does bc-backend do on this kind of message? We can tighten up the validation here to prevent that from getting past.

[carterworks]

Don't worry about the sonarqube report action failing - it is unreleated.