Fix references into nested placements and on asset delete (#285, #286)

Two findings from #269. A reference from a container into a placement
nested in it was dead from the start, and deleting an asset left
references to the objects it took along showing "(missing)".

- A reference is stored the way its holder shows the object. In a
  container tab that is q~x for content of a nested placement q.
- referenceCandidates translates it when the container is placed: in
  placement r, q~x becomes r~q/x. pathOfId and idOfPath in instance.ts
  do the mapping, objectChoices offers the same spelling the other way.
  The rule holds at any depth.
- Storing q/x as proposed in #285 was dropped. The container tab would
  then have had to translate its own ids.
- No migration. All projects and snapshots hold three references, none
  of them with ~ or /.
- Create container lets a reference to content of a member placement
  follow it. It was left dead before.
- Paste lets such a reference point into the copy. It kept pointing at
  the original before. Both go through the new renamedReference.
- Delete asset records what every holder shows before the cascade and
  clears every reference to an object that is gone afterwards, with
  dropReferencesToGone from #269. The row shows None, undo restores
  the references (#286).

Tests:
- Gate: 198 files, 2882 tests (2873 + 9), exit 0
- Unit object-references: 26 passed (17 + 9)
- e2e 1-17,57: 566 checks passed, 57 has +57i and +57j
- Six unit counter-probes fail between 1 and 3 tests each
- The browser counter-probe fails 57i and 57j as described in the
  issues
- e2e total 1609 is computed, not measured in a full run

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/core/model/instance.ts

@@ -105,6 +105,16 @@ export function splitInstanceId(id: string): { instanceId: string; path: string
   return { instanceId: id.slice(0, at), path: id.slice(at + 1) };
 }
 
+/** The template path an id of a holder's own view stands for once the holder is placed: `q~x` → `q/x`. */
+export function pathOfId(id: string): string {
+  return id.replace(ID_SEP, PATH_SEP);
+}
+
+/** The id a holder's own view gives the object at a template path: `q/x` → `q~x`. */
+export function idOfPath(path: string): string {
+  return path.replace(PATH_SEP, ID_SEP);
+}
+
 /**
  * Whether the object is only resolved from a template rather than stored in the holder. The
  * question is where it lives, not what its id looks like: unpacking keeps the derived id – so the