bug(cli): @ glob fallback parses LLM text and takes only first match

## What happened?

`packages/cli/src/ui/hooks/atCommandProcessor.ts:327-332` falls back to parsing LLM text and takes only the first hit:

```ts
const lines = globResult.llmContent.split('\n');
if (lines.length > 1 && lines[1]) {
const rawMatch = lines[1].trim();
```

Fragile `split('\n')[1]` assumes glob output format, ignores all but the first match, no workspace-trust check on the fallback path, and the `for (const dir of ...)` search above is serial `await` (slow multi-root). Wrong file can be silently injected into LLM context.

## What did you expect to happen?

Use the structured glob API (not `llmContent` string), rank/surface ambiguity to the user, parallelize multi-root dirs with abort, and enforce workspace-trust on the fallback.

## Client information

- Repo `google-gemini/gemini-cli` @ `main` `9c1b0a610`
- Area `packages/cli/src/ui/hooks/atCommandProcessor.ts:300-335`
- Platform: interactive `@file` completion

## Login information

N/A — repro: ambiguous `@config` with 2+ matches silently picks first with no prompt.

## Anything else we need to know?

Fix direction: structured results + disambiguation UI + `Promise.any`/parallel + trust check; test with multi-match fixture asserting prompt instead of silent first-pick.

Start in packages/cli/src/ui/hooks/atCommandProcessor.ts:300-335 and inspect the structured glob API, the multi-root search, and existing workspace-trust handling. Use the multi-match fixture described in the issue to verify that ambiguous @file results are surfaced for disambiguation rather than silently selecting the first match, with parallel search and trust enforcement covered.

Written by the indexing model from the issue text.