Validate the shard-lookup response in resolveCollectionDoc

[brylie]

`src/lib/client/yjs-client.ts`'s `resolveCollectionDoc` (used by `RelationPropertyCell.svelte` to connect to a relation field's target Collection) resolves its shard lookup with no validation — no `res.ok` check, no check that `shardId` is a non-empty string — before caching it (memoized per `collectionId` for the tab's lifetime) and connecting via `getShardDoc`.

A non-2xx or malformed response therefore creates and caches a `Y.Doc` for an invalid shard, and because the result is memoized, the bad connection sticks for the tab's lifetime instead of retrying.

PR #200 fixed the identical gap in `useCollectionConnection` (the shared hook every Collection renderer uses for its own Collection) per CodeRabbit's review; this is the same bug class in `resolveCollectionDoc`'s cross-Collection lookup, left out of that PR's scope.

• Check `res.ok` before parsing the shard-lookup response.
• Validate the parsed `shardId` is a non-empty string before caching/connecting.
• On failure, evict the cache entry (mirroring the existing network-rejection `.catch` path) so a later call retries instead of reusing a poisoned promise.
• Add/adjust a test asserting a non-ok or malformed shard response doesn't leave `resolveCollectionDoc` returning a doc for an unvalidated shard.

Done when: `resolveCollectionDoc` rejects and evicts its cache on a non-ok or malformed shard-lookup response, consistent with `useCollectionConnection`'s validation.

[brylie]

Set Priority P2 (unset → P2): same bug class as #203 but narrower blast radius (only relation-field cross-Collection lookups via resolveCollectionDoc, not every renderer's own connection) and lower likelihood (requires a non-2xx or malformed shard-lookup response, not just concurrent edits). A hardening fix mirroring an already-fixed sibling (useCollectionConnection, PR #200), not urgent.