[combobox] Shift+Home / Shift+End does not extend text selection when Input is inside Popup

# Bug report

## Current behavior

When `Combobox.Input` is rendered inside `Combobox.Popup` ("input inside popup" pattern, e.g. a button-triggered searchable dropdown), pressing **Shift+Home** (or **Shift+End**) while the input has text does **not** extend the native text selection from the caret to the start/end of the input value.

`Shift+ArrowLeft` / `Shift+ArrowRight` work correctly and do extend the selection one character at a time in the same input.

This reproduces in the official shadcn/ui docs demo for the base-ui Combobox "Popup" pattern (button trigger + `ComboboxInput` moved inside `ComboboxContent`), which is functionally the same "input inside popup" layout as this repo's `input-inside-popup` demo:

https://ui.shadcn.com/docs/components/base/combobox#popup

Steps to reproduce there:
1. Open the "Popup" example on the page above.
2. Click the trigger button to open the popup.
3. Type some text into the search input (e.g. "united").
4. Press `Home` — caret correctly moves to the start (no selection), as expected.
5. Now type again and press **Shift+Home** — expected: text from the caret to position 0 becomes selected. Actual: nothing gets selected (caret just moves, or nothing visibly happens), while `Shift+ArrowLeft`/`Shift+ArrowRight` correctly extend the selection one character at a time.

## Expected behavior

`Shift+Home` / `Shift+End` should extend the native browser text selection in the input, exactly like a plain `` outside of any Combobox, and exactly like `Shift+ArrowLeft`/`Shift+ArrowRight` already do inside this same Combobox input.

## Notes from investigation

We use this pattern in our own app (a button `Combobox.Trigger`/`ComboboxSelectTrigger` + `Combobox.Input` inside `Combobox.Popup`, `multiple` selection mode) and traced the relevant keydown handling across:

- `combobox/input/ComboboxInput.mjs` — its own inline `onKeyDown` for `Home`/`End` (caret-positioning / RTL support) explicitly bails out early when any modifier (`ctrlKey || shiftKey || altKey || metaKey`) is held, before reaching the `Home`/`End` branches.
- `internals/composite/root/useCompositeRoot.js` — its keydown handler also explicitly bails ("return to native textbox behavior") when `event.shiftKey` is true and the event target is a native input.
- `floating-ui-react/hooks/useListNavigation.mjs` — the `commonOnKeyDown`'s Home/End branch is gated by `!typeableComboboxReference`, so it should not apply when the reference is a typeable combobox input either.

All three layers we found appear to correctly defer to native browser selection behavior when Shift is held, so we weren't able to pin down from static source reading alone which handler (if any) is still intercepting the event, or whether this is a `mergeProps` ordering/interaction issue between these layers when the input is rendered inside a popup specifically (as opposed to being the trigger itself, e.g. the `async-multiple` chips-input-as-trigger demo, which does not exhibit this issue).

## Reproducible example

Any "input inside popup" Combobox with `multiple` (our case) or single-select (the shadcn docs "Popup" example, single-select) reproduces it. Minimal repro is the official `input-inside-popup` demo pattern:

```tsx

{/* ... */}

```

Type text into `Combobox.Input`, then press Shift+Home.

## Base UI version

`@base-ui/react` `1.6.0`

## Which browser are you using?

Reproduced on Windows/Linux with a physical Home key (not a Fn+arrow laptop substitute), so this isn't an OS/keyboard-hardware quirk. Exact browser/version not captured on our end, but also reproduces on the public shadcn docs demo above — happy to confirm exact browser/version if needed.

## Which OS are you using?

Windows / Linux

## Which assistive tech are you using (if applicable)?

N/A

Start by reproducing the issue with the input-inside-popup Combobox pattern, then trace keydown handling across combobox/input/ComboboxInput.mjs, internals/composite/root/useCompositeRoot.js, and floating-ui-react/hooks/useListNavigation.mjs. Determine which interaction prevents native Shift+Home and Shift+End selection, then verify that those keys select text in the popup input without regressing Home, End, or Shift+Arrow behavior.

Written by the indexing model from the issue text.