Refuse deletes that would remove a space's identity entities

[0xTaneja]

Follow-up to the personal-space wipe of many curators . This implements the SDK-level guard from the deletion-safety recommendations.

Why this belongs in the SDK

The incident deleted nothing through a skill. It ran a hand-authored TypeScript loop calling the delete path directly, in a different repo. Every skill-level protection - anchored-entity checks, dry-run expiry, the publishOps circuit-breaker - was bypassed because the caller read the docs and then wrote its own version without them.

An agent that freelances its own loop bypasses 100% of caller-side protection, so the invariant has to live where the ops are built.

What it does

geo.entities.delete(...) and the deprecated Graph.deleteEntity(...) now throw ProtectedEntityError when the target is a space's anchored entity: its page/home entity, or the Avatar or Cover image that entity points at.

Refusing to delete ba886bf1…: it is the home entity of space c45e5508…, which holds the space's name, description and identity. Pass `deleteAnchored: true` to delete it anyway.

These are the entities a caller iterating a space cannot tell apart from content - they're ordinary Image entities and one Page entity sitting in the same result set as everything else. That's why one stray loop takes the space's identity with it.

API

// Refused by default
await geo.entities.delete({ id: spacePageId, spaceId });

// Deliberate
await geo.entities.delete({ id: spaceAvatarId, spaceId, deleteAnchored: true });

ProtectedEntityError carries entityId, spaceId, and a reason of 'page' | 'avatar' | 'cover', so a bulk caller can skip an anchor and keep going rather than aborting at entity 400 of 11,000:

if (!(error instanceof ProtectedEntityError)) throw error;
console.warn(`skipped ${error.entityId} (${error.reason})`);

anchoredEntityIds() and spaceAnchorsQueryField() are exported too, so a
caller can resolve the anchor set up front and filter a work list before
deleting anything.

No extra round-trip

The anchors resolve inside the query deleteEntity already makes. This matters: the failure mode is a loop over thousands of entities, and a guard that doubled the request count is a guard people switch off.

Testing

• 34 new tests (protected-entities.test.ts, plus a block in delete-entity.test.ts), 579 total passing, biome and tsc clean.
• Verified against the live testnet API — ops built, nothing published:

target	result
personal space page entity	REFUSED
personal space avatar image	REFUSED
DAO space cover image	REFUSED
page entity + deleteAnchored: true	ALLOWED, 17 ops
ordinary news story	ALLOWED, 7 ops
page id passed dashed	REFUSED

What this does not cover

Recommendation 3 - the bulk-destruction threshold. deleteEntity sees one entity at a time, so it structurally cannot know it's the 400th call in a runaway loop. That check belongs where the full ops array is visible (personalSpaces.publishEdit / daoSpaces.proposeEdit), mirroring the publishOps >50-destructive circuit-breaker. Separate PR, happy to open it.