A cell cannot find its own runs without the last-execution stamp #3301

Split out of #3249, which is otherwise finished (#3270 made the currency verdict fail closed; #3300
made a swallowed stamp reported rather than silent, and argued why the two "put a marker on the
cell" shapes are unsound).

What is left

A cell reads its own run history from one denormalised pointer: CodeConfiguration.LastActivityPath,
written by the last-execution stamp. When that stamp does not land, the pointer is not there, and on
the next page load the cell is indistinguishable from a cell nobody has ever run — even though the
run happened and its record is durable.

That last part is the point. The run is not lost. CodeNodeType.HandleExecuteScript creates the
Activity node before it dispatches, and stamps the originating cell onto it:

Content = new ActivityLog("ScriptExecution")
{
    Id = activityId,
    HubPath = hub.Address.Path,   // ← the Code node
    Status = ActivityStatus.Running
}

So the cell → run edge exists in the data; it is only missing in the direction the view reads it.
Nothing today follows it back.

Why this is not closed by #3300

#3300 deliberately reports the stamp failure to an operator (one Error, event id 3249) and
argues that recovering it on the cell is not possible from the dispatching hub: every scheme that
writes a marker onto the cell is a second write to the node whose first write just failed. That
reasoning is written up in Doc/Architecture/ScriptExecution → "When the stamp does not land".

It says nothing about the viewer, because the fix for the viewer is not a write at all — it is a
read that does not depend on the stamp.

Shape of a fix

A surface that answers "has this cell been run?" from a listing over _Activity filtered on
ActivityLog.HubPath, falling back to the stamp rather than depending on it. That is a valid CQRS
use — a listing by predicate, where a stale negative is harmless — and it is the same fallback
shape MeshWeaver.Plugins#1288 already applied to the output pane, which prefers
ExecuteScriptResponse.ActivityLog over the stamp for the current session.

Two halves, and they are in different repos:

• core — ActivityLog.HubPath and CodeConfiguration live here, and if the lookup is worth
  making canonical (rather than re-derived per view) it belongs beside
  CodeOutputCurrencyExtensions.OutputCurrency, which is already the one rule every surface uses.
• MeshWeaver.Plugins — CodeViews.IsOutputStale is the toolbar that renders the verdict.

Cost, stated

A per-cell activity listing is not free on a notebook with many cells. Whether this is worth a query
per cell, a batched one per page, or only a lazy check when a cell would otherwise render
NeverRun, is the design question — and "only when it would say NeverRun" is probably the answer,
since that is the one state where the lookup can change the outcome.

Not in scope

The stamp's own failure reporting (#3300) and the currency rule (#3270) are done.