`drop_attribute` never reclaims `Table.indices`

## Summary

`drop_attribute` removes the attribute from the schema and drops its data, but the entry in `Table.indices` is never removed. The map keeps the attribute's key, and with it the store handle for an index that no longer has an attribute behind it.

## Confirmed by source read

Nothing in the repository ever deletes an entry from that map:

```
$ grep -rn "delete .*\.indices\[" --include='*.ts' --include='*.js' .
(no matches)
```

`dropAttribute` (`dataLayer/schema.ts:242`) calls `harperBridge.dropAttribute()` and then `dropAttributeFromGlobal()`, which clears the global schema. Neither touches `Table.indices`. Every read site — `resources/databases.ts:1774`, `:2210`, `:2230`, `:2267` — continues to see the entry, and the close loop at `:1307` will still walk it.

So the state is not merely a leaked reference: the map is the live lookup for index dbis, and it now contains one for an attribute the schema says doesn't exist.

## Reproduction context

Reproduced under a **measured** 4-way worker spread (dispatch task `qa-wave-2026072509`), which matters because the original observation assumed the worker spread rather than measuring it. That makes this an evidenced precondition rather than an assumed one.

## Open questions

- Whether the retained dbi is only a leak (memory plus an open store handle per dropped attribute) or can also serve reads — i.e. whether a query naming the dropped attribute can still hit the stale index.
- Whether re-adding an attribute of the same name reuses the stale entry, and what happens to its contents if it does.

Both are worth answering before choosing the fix, since "delete the key on drop" and "make the map authoritative against the schema" are different-sized changes.

## Related

- #2099 — ADD-backfill phantom index entries, the sibling finding this issue was originally filed alongside
- #1647 — Indexing & query-correctness epic

---

_Originally filed as a raw dispatch finding covering two separate findings; split during backlog triage so each carries its own evidence. This issue is F-193._

Start with `dataLayer/schema.ts:242` and trace `dropAttribute`, `dropAttributeFromGlobal`, and the index handling in `resources/databases.ts` at the cited lines. Investigate whether dropped attributes' stale index entries affect reads or re-adding an attribute before selecting a fix. Done means the index map no longer retains or serves entries for attributes absent from the schema, with the relevant behavior verified.

Written by the indexing model from the issue text.