feat(app): the app scans on its own, WebView included (phase 16)

[hami9]

What and why

Phase 16 complete. The app fetches through Rust with no CORS, runs core's pipeline, renders client-rendered shops in an embedded WebView, and writes a CSV straight to disk. No browser involved at any point.

Earlier commits on this branch landed HTTP, the scan wiring and the save dialog, and those were verified against a real shop. This one adds the WebView — the failure the CLI has always had, where a JS-built shop reads as zero products.

Two capabilities, not one. rendered_html is what this phase needs. evaluate is what phase 27 needs to read Core Web Vitals out of the Performance API, and it is written now because adding it later means reopening the window plumbing rather than writing one more command.

The render windows get none of Tauri's IPC. They load somebody else's page, and a scanned shop that could reach invoke would have the filesystem and HTTP client of this process. Only http(s) URLs are rendered — a file: URL arriving from a scanned page's own markup would point the renderer at the local disk.

Five bugs, and every one of them was ours

Worth reading, because each presented identically as "this site does not render" and they are recorded in packages/app/README.md so the next session does not rediscover them:

1. wry drops the eval callback while a page is loading. webkitgtk/mod.rs pushes the script onto pending_scripts and returns Ok(()) without ever calling back. So an unanswered eval means not loaded yet, never broken — treating it as failure returned the pre-JS shell every single time.
2. A window that is never mapped never starts its webview. visible(false) is the obvious choice and silently prevents the page loading at all.
3. A time budget has to measure time. Adding a poll interval per iteration counts turns; an iteration waiting on an unanswered eval takes far longer, so a "15 second" ceiling kept a window on screen for minutes.
4. A cheap probe and a megabyte payload cannot share a timeout. Two seconds is right for outerHTML.length and made the real read come back empty — which reads exactly like a page that rendered nothing.
5. Loading and settling need separate budgets. Sharing one meant a slow first load spent the whole allowance before a single useful measurement: the same page returned 415 KB when it loaded fast and nothing when it did not.

The fallback is gated on zero products, not "fewer than expected". Rendering costs a second page load plus every subresource — real load on someone's server (§10) — and a partial result is a real result. An empty one is the only case with nothing to lose.

How it was verified

npm run check passes, 835 tests. cargo fmt, clippy -D warnings and cargo test clean.

Against live Persian storefronts, not fixtures:

Shop	Result
kgkala.ir (WooCommerce)	43 CSV rows via Layer A, every variation, §7.6 values matching
digikala.com (Next.js)	rendered 415 KB, 379 products
technolife.com	rendered 1.25 MB, zero products
zitu.ir	rendered 414 KB, 2 products

The finding that matters most

Rendering is not extraction. technolife renders its entire grid and yields nothing, because the rendered page carries ld+json=2 (Organization and Breadcrumb), itemtype=0 and schema.org/Product=0. Layer B is behaving correctly — there is no structured data to read.

So the WebView fixes "the HTML was empty". It does not fix "this shop publishes no structured data" — that is Layer C's job (phase 19), and the two are meant to compose: render first, extract from the rendered DOM. phase-17.md carries that into the next session.

This also adds the logging that made any of the above diagnosable. A failing Layer A used to look identical to a page with no markup; §11 says a failure should be able to explain itself, and it could not.

Checklist

• The commits follow Conventional Commits
• npm run check passes (format, lint, typecheck, tests)
• New behaviour has tests
• No currency unit is inferred, and no field is invented to fill a blank

🤖 Generated with Claude Code