Micro-frontend shell never bootstraps: style-loader "Couldn't find a style target" on developer.intuit.com (headless Chrome unaffected)

docker run --rm h4ckf0r0day/obscura:latest fetch \
  "https://developer.intuit.com/app/developer/qbo/docs/api/accounting/all-entities/customer" \
  --dump text

# valid settle strategies, generous budget
--wait-until networkidle0 --wait 25 --timeout 90
--wait-until networkidle2 --wait 25 --timeout 90
--dump markdown
--stealth

Compiling and pre-filling your Intuit info...

Page loaded: https://developer.intuit.com/... - "Intuit Developer"

ERROR obscura::console: Shell - failed to fetch AppPluginBundle {...,"appPlugin":"ext-dev-portal-ui","appPluginVersion":"1.69.5","clientMode":"WEB","runtime":"CSR",...}
  Error: Couldn't find a style target. This probably means that the value for the 'insert' parameter is invalid.
    at u (eval at execute (<obscura:bootstrap>:369:28), <anonymous>:1:3585)
    at v (eval at execute (<obscura:bootstrap>:369:28), <anonymous>:1:4622)
    at c (eval at execute (<obscura:bootstrap>:369:28), <anonymous>:1:3267)
    at e.exports (eval at execute (<obscura:bootstrap>:369:28), <anonymous>:1:4955)

ERROR obscura::console: Shell - failed to fetch appPlugin from AppPluginLoader {...}
  Error: Couldn't find a style target. ...

ERROR obscura::console: Shell - Application Bootstrap failed {...}
  Error: Couldn't find a style target. ...


The same error text propagates through all three stages, so the style-target failure appears to be the first cause rather than a downstream symptom.

---

## What I ruled out

The error originates in webpack `style-loader`'s `insertBySelector` runtime, which throws exactly this message when `document.querySelector(options.insert)` returns null (and, for an iframe target, when `contentDocument.head` is unavailable). I probed each mechanism in isolation, A/B against headless Chrome on an identical constructed DOM. **All behave identically — none of these is the cause:**

| Probed | Result vs Chrome |
| --- | --- |
| `script.onload` property assignment | fires, identical |
| `script.addEventListener('load')` | fires, identical |
| `onload` **content attribute** (cf. #768) | fires, identical |
| dynamic `import()` | resolves, identical |
| `fetch()` | 200/ok, identical |
| `querySelector` / `querySelectorAll`, 23 selector forms (tag, id, class, descendant, child, attribute bare/single/double-quoted, `:root`) | **0 divergences** |
| style-loader's iframe branch: `window.HTMLIFrameElement`, `instanceof`, `contentDocument`, `contentDocument.head`, `appendChild` into it | identical, append succeeds |
| `document.head`, `createElement('style')`, `appendChild`, `insertBefore(s, null)` | all succeed on both |

Also checked and **not** the cause:

- **Not a settle/timing problem.** `--wait 25` with `networkidle0` and `networkidle2` gives byte-identical output to the default.
- **Not bot detection.** Site telemetry reports `isScraperBot:false`, `browserType:green`; `--stealth` changes nothing.
- **Not #699** (page task errors killing the event loop, fixed in `ad29745b`). On a `main` build the `page task error, continuing the event loop` path never fires here — the shell *catches* the style error and reports it via `console.error`, so it was never an uncaught task error.

So the style-target resolution genuinely fails on this page, but not through any primitive I could reproduce standalone — it looks downstream of an earlier divergence inside the vendor's own bundle, which I can't bisect from outside.

## Minor, found while investigating

`--wait-until` silently accepts any value: `obscura fetch https://example.com --dump text --wait-until totalnonsense` exits 0 with no error or warning, apparently falling back to the `load` default. The documented set is `domcontentloaded | load | networkidle0 | networkidle2`. This cost me a round of testing that I believed had exercised `networkidle` but had not. Rejecting unknown values (or warning) would make that failure loud. Happy to split this into its own issue if preferred.