Add a Product E2E Eval

Use this skill for Product E2E Evals: real Chromium, Paperclip server, database, runner, provider, and optionally Daytona. Everyday Workflows are in this family even when their packaged results are imported into Evalbook. Runner protocol cases against the mock control plane belong in add-runner-eval.

Locate the repository using PAPERCLIP_ROOT when supplied, or git rev-parse --show-toplevel from a checkout. From outside Git, inspect workspace roots such as ~/paperclipai/paperclip; verify the selected root contains tests/runner-e2e and packages/paperclip-runner. Run commands from that repository root. The copied skill may live outside the checkout. Read doc/evals.md, then the authoritative tests/runner-e2e/README.md, FIXTURES.md, SECURITY.md, and EVERYDAY-WORKFLOWS.md for the selected area. Inspect the nearest existing catalog entry, case, harness flow, matcher, evidence writer, and report test before changing anything. Keep the user journey on production browser/API surfaces; do not add private runner hooks or direct fixture database writes.

Define one bounded workflow with a clear user outcome, durable state assertions, and independent evidence. Declare profile, environment, expected provider turns, timeout, cleanup, screenshots, artifact checks, and billing scope. Keep credentials and secrets out of catalog data, screenshots, fixture metadata, logs, and tracked files. Daytona images must be immutable digest references. Use the existing result validator, failure classifier, screenshot policy, and Product E2E report pipeline rather than duplicating them.