Retire lightpanda in favour of ego-browser; bump both submodules

[NagyVikt]

Started as a submodule-pointer bump. The bump turned a light red, and the reason
turned out to be worth fixing properly rather than working around.

The bug the bump exposed

#121 removed the lightpanda MCP from every profile but left the skill
behind. So core shipped browser/lightpanda, which declares
requires_mcps: [lightpanda], while nothing supplied that server. Every session
carried a skill that could not work, and the smart-loader kept offering it —
literally rendering browser/lightpanda (needs MCP: lightpanda) in the hook
output.

It stayed invisible because the committed catalog/index.json was stale: its
mcpProviders map still named twelve profiles, core among them, as lightpanda
providers. summon.test.ts read that map, saw "core provides it", and went
green. Rebuilding the index (it was also lagging the catalog by a whole skill)
made it honest — mcpProviders["lightpanda"] is now absent entirely — and the
stale assertion failed.

Worth stating plainly: of the 29 skill→MCP requirements in the tree,
browser/lightpanda was the only one with no provider at all.

What this PR does

Retires lightpanda. ego-browser covers the same ground — headless
navigation, scraping, DOM extraction — and also paints pixels, which was the
stated gap that forced the old two-engine handoff. Removed from core and
browser; four personas (commerce, webshop, gstack, x-growth-bot) that
routed agents to it now route to ego-browser. agent-browser and webwright
keep their entries.

Rebuilds summon.test.ts on a pair that can actually hold. Now
deployment/coolify + active backend: the summoned profile ships the skill, a
different profile supplies the MCP — which is the distinction the test exists
to make. A comment records why the old pair must not come back.

Bumps both submodules to their merged mains (the original purpose):
resources/skills → opencue/skills#17 + #19 (the ego-browser skill, the
smart-lookup --annotate fast path the hook needs, ladder-snapped calibration);
resources/mcps → opencue/mcps#8 (codegraph in the claude snapshot, context7 off
npx).

Verification

• Full suite on this branch: 3023 pass, 0 fail — up from main, which is
  green on test but only because of the stale index.
• All 86 profiles parse; docs-facts count assertions still hold.
• Regenerating the index after the profile edits produces a byte-identical file,
  so no follow-up submodule bump is needed.
• Only remaining lightpanda string in profiles/ is a deliberate note in
  gstack recording that core used to ship it.

validate will still fail on the pre-existing openaiDeveloperDocs reference —
unrelated, pull_request-only, and #121 merged with the same failure.

[NagyVikt]

Holding this: the bump exposes a stale test, and the fix is a product decision

CI on this branch adds exactly one failing test that main passes:

summon > mcp_status reflects the active session's loaded MCPs
  expected "ok", received "missing:lightpanda"

It is not a regression in the bump. The bump makes main honest, and main
was passing on a lie.

The chain:

1. #121 chore(profiles): drop the lightpanda MCP from the profiles that pin it
   removed lightpanda from every profile that declared it, including core.
2. summon.test.ts still encodes the pre-chore(profiles): drop the lightpanda MCP from the profiles that pin it #121 world — its comment literally
   reads "browser/lightpanda needs the lightpanda MCP; core loads it."
3. That test kept passing only because the committed catalog/index.json was
   stale: its mcpProviders map still listed twelve profiles as providing
   lightpanda, core among them.
4. This PR rebuilds that index (it had also been lagging the catalog by a whole
   skill). The rebuilt map is correct: mcpProviders["lightpanda"] is now
   absent — no profile provides it at all.

Verified: browser/lightpanda/SKILL.md is byte-identical across both submodule
commits, so nothing about the skill changed; only the provider map did.

Why I am not just patching the assertion

core still ships browser/lightpanda, and that skill still declares
requires_mcps: [lightpanda]. So after #121, cue hands every user a core skill
whose MCP nothing provides — mcp_status will now honestly say
missing:lightpanda in every session. Rewriting the test to expect that would
lock in the inconsistency rather than surface it.

There is also no drop-in substitute: core currently provides headroom,
dataforseo, codegraph and context7, and no skill in the tree declares
requires_mcps for any of them — so the test's "ok" branch cannot be
satisfied by live profile data at all any more.

Someone needs to pick one:

• chore(profiles): drop the lightpanda MCP from the profiles that pin it #121 went too far — restore the lightpanda MCP on the profiles that ship
  the skill, and the test passes again as written.
• chore(profiles): drop the lightpanda MCP from the profiles that pin it #121 was right — then browser/lightpanda should come out of core too,
  and the test needs rebuilding against its own fixture instead of live profile
  content.

The resources/mcps half of this PR is independent and unaffected. Say the word
and I will split it out so it can land on its own.