Debug console dedup only understands the default SimpleConsoleFormatter shape

Follow-up from #19129, which fixed the duplicated/uncolored AppHost logs in the VS Code debug console (#18047).

The extension deduplicates by reconstructing a log record from the AppHost's console output and correlating it with the copy that arrives over the backchannel. To do that it has to parse `SimpleConsoleFormatter`'s output, and it only understands the default shape:

```
warn: Example.Category[7]
the message body
```

If the AppHost sets `TimestampFormat`, `SingleLine` or `IncludeScopes`, the header no longer matches and the record falls back to being passed through raw. It degrades rather than breaks — you get today's behavior, so the line shows up twice and uncolored — but it's still wrong.

Reproduced against the shipping coordinator with `TimestampFormat` set:

```
[stdout] "\u001b[33mMy.Real.Category: Warning: a genuine warning\u001b[0m\n" <- backchannel copy, styled
[stdout] "2026-08-07 12:00:00.000 warn: My.Real.Category[3]\n a genuine warning\n" <- console copy, unparsed
```

### What I think we should do

Stop guessing the format. The AppHost already knows its effective `ConsoleFormatterOptions` — it can read `TimestampFormat`, `SingleLine` and `IncludeScopes` off the resolved options — so it can report them once over the backchannel and let the extension build an exact parser instead of a heuristic one.

Rough shape:

- AppHost reports the effective console formatter options (alongside the existing capability handshake).
- CLI relays them to the extension.
- `AppHostLogOutputCoordinator` builds its header pattern from the reported options rather than assuming the default.
- Keep the current parser as the fallback for AppHosts that don't report anything.

`IncludeScopes` needs a bit more than parsing: the scope text is in the console copy but not in the backchannel entry, so the two records aren't equal and correlation would need a scope-aware identity on both sides. That part could be split out if it's not worth it.

### What I don't think we should do

Widening the header regex to tolerate a leading timestamp. It handles one of the three options, it makes the pattern much less specific, and it's strictly worse than having the producer tell us.

Suppressing the AppHost's console provider when the extension is going to render the backchannel copy also came up, and it's tempting because it deletes the parser entirely. I don't think we should: the console path is synchronous and in-process while the backchannel path is async and cross-process, so making the backchannel the only path loses exactly the records you most want during a failure — the fatal and shutdown ones whose channel never drains. It also ties the AppHost's own logging configuration to which editor launched it.

Filing this rather than growing #19129 further, since it's a new wire contract and the fallback parser is needed either way. Not urgent unless non-default formatter configuration turns out to be common.

Trace the existing capability handshake, CLI relay, and AppHostLogOutputCoordinator flow described in the issue. Start by locating how the resolved ConsoleFormatterOptions and current fallback parser are handled. Done means non-default TimestampFormat and SingleLine settings are reported and parsed accurately, while the existing fallback remains for older AppHosts; IncludeScopes may remain separate.

Written by the indexing model from the issue text.