[Bug]: Renaming a problem set then immediately adding items shows the old name as the destination

[dqnykamp]

Summary

setAddTo(activity) captures the loader's activity object at click time, so the "add to" destination keeps whatever name the loader last returned. Rename a problem set and click Add → Items from Explore before the rename's revalidation lands, and the destination is captured with the old name — which then persists across navigation and is shown in the copy dialog: "2 items added to: Untitled Problem Set" for a problem set the user just renamed to "My problem set".

Cosmetic for the user, but it is also a persistent CI failure: addToCompoundActivity.cy.ts → "Add to problem set from Shared Activities" exhausts all three retries on main, so e2e-tests (group2) has been red since at least 2026-08-12.

Steps to reproduce

1. My Activities → New → Problem Set.
2. Immediately rename it via the title field — type My problem set and press Enter.
3. Without pausing, click Add → Items from Explore.
4. Select two documents and click Add.
5. Read the confirmation dialog.

The window is short locally, which is why it shows up more reliably in CI than by hand.

Expected behavior

The dialog names the destination as it currently is: 2 items added to: My problem set.

Actual behavior

2 items added to: Untitled Problem Set — the name the problem set had before the rename.

Doenet version or commit

main — reproduced in CI on run 31609610288 (2026-08-12), independent of any open PR.

Browser / OS / Node version

Chrome, CI (Ubuntu). Not browser-specific.

Relevant logs

1) Add to compound activity tests
     Add to problem set from Shared Activities:
     Timed out retrying after 10000ms
     + expected - actual
     -'2 items added to: Untitled Problem Set'
     +'2 items added to: My problem set'
     at ./e2e/Content Lists/addToCompoundActivity.cy.ts:335:40

# the neighbouring case in the same spec is racy too — it fails twice then passes
(Attempt 1 of 3) Add to problem set from Explore
(Attempt 2 of 3) Add to problem set from Explore
  ✓ Add to problem set from Explore (15138ms)

Additional context

Root cause: apps/app/src/views/CompoundActivityEditor.tsx does setAddTo(activity) in the onClick of the "Items from Explore" / "Items from My Activities" menu items. activity is loader data, and the rename in apps/app/src/widgets/NameBar.tsx goes through fetcher.submit, so activity.name only updates once revalidation completes. Clicking in between snapshots the stale object, and because addTo lives in SiteContext it survives the navigation to Explore and is read by CopyContentAndReportFinish as desiredParent.

Storing a snapshot is the underlying problem — the destination is identified by contentId, so the displayed name could be resolved fresh at render time instead of carried along. Alternatively addTo could be refreshed when the loader data for that contentId changes.

Worth noting the same staleness would affect anything else read off the captured object, not just the name.