Vendor mdbase.view 1.0.1 so saved views validate under any type key

[callumalpass]

Why

Reader saves library views as mdbase.view records by naming the type (create({ type: "view", ... })). The view starter in mdbase.view 1.0.0 pinned type: { const: view }, required type, and closed its top level. In collections whose settings.explicit_type_keys is [mdbase_type] (used because type holds CSL data), every new view failed with schema_required: type / schema_additional_properties: mdbase_type.

mdbase-contracts #14 (7d3d31e) published mdbase.view 1.0.1. It ships the version-2 starter, which has no pinned type and accepts unknown top-level fields, with upgrade_from set to the unmodified 1.0.0 starter.

What

• Replaces apps/reader/mdbase/packs/mdbase.view-1.0.0.json with the published dist/packs/mdbase.view/1.0.1.json, copied byte-for-byte, and points reader-manifest.mjs at the new file.
• Regenerates public/.well-known/mdbase-app.json, src/generated/mdbase-app.json and the extension's src/generated/mdbase-app.json with the repo scripts under MDBASE_ENV=production. project_url and homepage are still https://reader.mdbase.dev/.
• The contract the pack provides is unchanged (mdbase.view@1.0.0, sha256:0918acef…), so requirements.contracts does not change. Only the pack version and the starter change.
• verify-manifest.mjs already sends every pack through referenceInstallerProvision(), so the view seed's upgrade_from is stripped for the JS installer the same way as for Reader's own pack.
• reader-type-pack.test.mjs:
  • Asserts the view pack is 1.0.1 and provides mdbase.view@1.0.0.
  • Pins the pack's canonical-JSON digest sha256:b32222bc…, which matches desired.digest from mdbase packs assess.
  • Adds a check that a view record named by type validates and projects through the mdbase.view contract under both [type] and [mdbase_type].

Note: @callumalpass/mdbase 0.3.0-rc.5's create() still requires the type's match rule (where: { type: view }) to hold, so it rejects create({ type: "view" }) in a [mdbase_type] collection with match_failed. Connect's engine (mdbase CLI beta.123) accepts it. The new test therefore writes the record the way the engine records it and validates that record, instead of calling the JS SDK's create.

Verification

• pnpm check (lint, typecheck, all unit tests) passed. apps/reader: node tests 18/18 and vitest 390/390. extension: 168/168. Packages: core 110, connect 123, renderer-pdf 65, migration 42, renderer-epub 32, web-capture 32, markdown-editor 28, reading-surface 21, renderer-html 16, platform 6, electron 2. Architecture: 11.
• MDBASE_ENV=production pnpm build (includes manifest:validate) passed and left the tree clean.
• mdbase CLI 0.1.0-beta.123 in a scratch collection with explicit_type_keys: [mdbase_type]:
  • Fresh install: packs assess + packs apply of 1.0.1 worked. Then mdbase create --type view (with type: article-journal as data) returned valid: true, wrote mdbase_type: view, and mdbase validate reported no diagnostics.
  • Upgrade: with 1.0.0 installed, create --type view failed (schema_additional_properties: mdbase_type, schema_required: type). packs assess of 1.0.1 then returned status: upgrade, _types/view.md: update, and the schema and contract unchanged. After apply, create --type view was valid and mdbase validate was clean.