fix(ui): block context menu acts on the embed, not its target - #13099

Fixes logseq/db-test#1104.

Right-clicking a Node embed's bullet and choosing Cut deletes the embedded target
and leaves the embed in place.

The bullet right-click handler derives block-id from the bullet's blockid
attribute. On a row rendered through :block/link that holds the linked block's
uuid, while the linking block's own uuid is in originalblockid. The handler never
reads the latter, so block-context-menu-content — and every block-level action in
it — is built around the embed target.

The same handler stores the .ls-block row via conj-selection-block!, and that row
does carry originalblockid, which is why the menu's selection-based items behave
correctly while its block-based items do not.

This prefers originalblockid when present:

ls-block-el (some-> target (.closest ".ls-block"))
block-id (or (some-> ls-block-el (.getAttribute "originalblockid"))
             (some-> block-el (.getAttribute "blockid")))

Rows inside an embedded page carry no originalblockid, so right-clicking one still
targets that inner block.

Scope

This is not the same defect as logseq/db-test#1105. That one was introduced by the worker
migration (fe65e36f13); this one predates it — cut-block! has never resolved
originals, and the pre-migration version differed only in using a synchronous
db/entity.

It also redirects the other block-level menu actions — notably the block-level
delete via delete-block-aux! — to the embed rather than its target. That appears
to be the intended behaviour, but it is a wider change than Cut alone and deserves a
look.

Verification

Built from source, driven through the real UI both by injected input and by hand,
with outcomes read from client-ops.forward_outliner_ops and the fixture restored
before each trial. Six embed shapes (block with content, block with children, empty
block, empty page, page with blocks, embed-of-embed chain): the menu's Cut removes
the placeholder and leaves the target intact in every case, with no change to the
keyboard gestures or to "Delete selected blocks".

One caveat on that: those runs were on a build that also carried the logseq/db-test#1105 fix, since
both were in hand by then. This change is independent of it — it touches only how
block-id is derived — but it has not been exercised in isolation.