genie #mr member resolution picks gutted worktrees by existsSync alone

Context

genie's #mr/<member>/... import resolution (packages/@overeng/genie/src/core/import-map/sync-resolver.ts, deriveStoreWorktreePathFromLockMember) selects a member worktree with fs.existsSync(derivedPath) alone. A registered-but-gutted worktree (files deleted mid-repair, or a half-created registration) passes the check, so every generator import through that member fails with a bare Cannot find module — and the failure surfaces only later as GenieGenerationFailedError on an unrelated downstream file (e.g. a consumer repo's flakes/*/package.json), with the real path truncated in the reporter output.

Observed live: an in-progress store repair left refs/commits/<sha> registered and locked with most files deleted; every genie check in the consuming workspace went red until the repair finished.

Suggestion

Validate the candidate worktree beyond existence (e.g. the member's package.json / a marker file at the derived root), so a broken registration falls through to the next selector (ref worktree) instead of poisoning generation; and include the resolved path in the import-failure message.

Impact

Transient but total: any consumer workspace's lint:check:genie / genie:check fails while a store repair holds a gutted worktree, with no signal pointing at the store.

Start in packages/@overeng/genie/src/core/import-map/sync-resolver.ts, especially deriveStoreWorktreePathFromLockMember, and trace the member worktree selection and import-failure reporting. Reproduce or inspect the gutted-worktree case, then verify lint:check:genie or genie:check uses a valid fallback and exposes the resolved path when resolution fails.