Move cpp-on-the-web from skills-src into guides

[sbc100]

Initial PR to see if we can get C++ on the web into guide form.

This PR was created using the following steps:

• Merge library-porting.md and SKILL.md into single guide.md
• Remove assets
• Add an expectations.md
• Ran gd dev guides/cpp-on-the-web --no-test to generated targets directory

See #1385

[sbc100]

It looks like the basics lint checker is failing on guides/cpp-on-the-web/targets/daily-grind/grader.ts.. which is an auto-generated file.

Should these be excluded from lint checking? Presumably we don't go in and and edit these files?

[sbc100]

Results for this simple task are pretty good even unguided it seems. I ran a local eval and got the following results:

$ gd eval guides/wasm/cpp-on-the-web/targets/daily-grind
$ cat /usr/local/google/home/sbc/dev/wasm/modern-web-guidance-src/harness/results/test-2026-08-26T14-04-17/evals.md

Group	Pass Rate	Test Runs
Unguided	83% (5/6)	1
Guided	100% (6/6)	1

DAILY-GRIND - CPP-ON-THE-WEB - UNGUIDED (Median: 83%)

Pass rates across runs: 83%

Run 1 Details (5/6)

Status	Expectation
✅	The application loads the WebAssembly module as an ES6 module
❌	The WebAssembly module is built with optimizations enabled and debug info stripped
✅	The C++ image filter function is exposed and callable via Embind
✅	Applying the filter modifies the image or canvas pixels in the DOM
✅	The WebAssembly memory buffer used for pixel data is freed after processing
✅	The browser console contains no unhandled errors or exceptions during module initialization and filter execution

DAILY-GRIND - CPP-ON-THE-WEB - GUIDED (Median: 100%)

Pass rates across runs: 100%

Guides Consumed: cpp-on-the-web

Tools Used: modern-web-guidance

Run 1 Details (6/6)

Status	Expectation
✅	The application loads the WebAssembly module as an ES6 module
✅	The WebAssembly module is built with optimizations enabled and debug info stripped
✅	The C++ image filter function is exposed and callable via Embind
✅	Applying the filter modifies the image or canvas pixels in the DOM
✅	The WebAssembly memory buffer used for pixel data is freed after processing
✅	The browser console contains no unhandled errors or exceptions during module initialization and filter execution