Support versioned types as collection schemas

[shavtvalishvili]

This lets a collection use a hyperschema versions: type as its row schema, so old rows read back in the newest shape - the same upgrade-on-read versioned types already give wire messages.

Three things stood in the way: key paths don't look through the wrapper, the derived value schema doesn't know about versions, and toCode isn't told where messages.js lands (it throws once a maps file is involved).

With this, a collection whose schema is a versioned type works end to end:

• key paths resolve through the latest version, in both path resolvers (nested paths included)
• the value schema derives one variant per version, wrapped back into a derived versioned type carrying the maps - so a stored v1 row reads back in the latest shape
• the builder passes filename to toCode so the maps import path can be computed

Tests: a stored v1 row reads back mapped after the schema gains a v2, and a key path through a nested versioned field.

Depends on holepunchto/hyperschema#58 (reload with forward version refs) and holepunchto/hyperschema#59 (maps path persisted in schema.json) - the tests exercise both, since hyperdb's builder reloads schema.json on its own.

One heads-up: the new test re-requires messages.js between builds itself. The test helpers' build() refreshes the generated index.js but not messages.js - and fixing that globally makes define versionField on collection fail on main (it currently decodes gen-3 rows through gen-1's cached codec). I left the helper untouched and scoped the refresh to the new test; the versionField observation is filed as #104.

---

Part of a series making versioned types usable end-to-end: holepunchto/hyperschema#58 (reload fix), holepunchto/hyperschema#59 (maps persistence), holepunchto/hyperschema#60 (encode default), #103 (versioned collection schemas), holepunchto/hyperschema-ts#9 (emitted types). Each stands alone except hyperdb#103, which needs #58 + #59.