fix(cdp): embed objectId as a JSON literal at every lookup site

Runtime.getProperties escaped the objectId with a backslash and quote
replace pair and spliced the result into __obscura_objects['{oid}'].
A raw newline ends that literal, so the generated snippet was a syntax
error, page.evaluate returned no array, and the handler fell through to
result: [], reporting nothing. A client walking a nested object saw an
object with no properties rather than a failure.

The ids are not all client-supplied. getProperties mints child ids as
parent + "::" + key, and the key is a property name off a page object,
so the page decides which characters land inside the literal.

dom.rs had its own escape_object_id, cited in #709 as already robust,
but it was the same two replace calls with the same hole. Its fallback
was worse than an empty list: describeNode's unwrap_or(0) answers with
node 0, so a handle that failed to resolve was described as the
document instead of erroring.

Both files now build the literal through util::object_id_literal, which
serialises the id as JSON. JSON string syntax is a subset of
JavaScript's, so it covers the quote and backslash the replace pair
handled plus every C0 control it did not. Sharing one helper is what
keeps the two domains from drifting apart again. Same approach as the
Input.insertText fix in 524f2a9.

Fixes #709.