Hosted type-scoped applications need a safe malformed-frontmatter repair path

[callumalpass]

Summary

A hosted record with unparseable frontmatter cannot be repaired through an otherwise authorized type-scoped application. Exact-record authorization correctly fails closed because Connect cannot prove the record's current type, but there is no sufficiently narrow repair path for the application that encounters the record.

This can leave user-owned data operationally stranded: the record exists, but ordinary clients cannot fix the syntax that prevents its classification.

This is related to, but distinct from:

• Hosted provider can persist records that become unauthorizable after malformed wikilinks #359, where malformed body relationships incorrectly block authorization even though type evidence remains complete.
• Fence mirrors on invalid local records #339, which prevents mirrors from publishing invalid local records and adds narrowly fenced mirror recovery behavior. Existing hosted records, legacy clients, imports, and other intake paths still require a coherent hosted repair contract.

Reproduction

1. Create a valid hosted record belonging to a type available to a type-scoped application.

2. Cause the hosted exact record to contain unparseable YAML frontmatter (for example through a legacy/import/mirror path):

   ---
   title: [
   ---
   Body

3. Attempt an ordinary scoped update that repairs the frontmatter.

4. Observe scope_classification_unavailable or scope_denied before the repair can be applied.

The #359 candidate regression intentionally confirms this fail-closed behavior, but it does not provide a recovery path.

Required security invariant

Connect must not authorize an unrestricted ordinary update based only on a proposed after-image. Otherwise an application could target an unrelated malformed record and rewrite it into one of its own allowed types.

At the same time, fail-closed authorization should not mean permanent loss of repair access for collection-owned data.

Expected behavior

Provide a narrowly authorized recovery mechanism that:

1. Does not expose malformed record contents to an application that lacked prior authority.
2. Binds repair authority to trusted prior evidence, an explicit collection-owner capability, or another non-forgeable authorization fact.
3. Canonically classifies and validates the complete proposed after-image.
4. Commits only when the repaired after-image is within the authorized scope.
5. Rejects atomically, preserving the original bytes and revision, when repair validation or authorization fails.
6. Produces actionable diagnostics so clients can distinguish “repair required” from an ordinary scope denial.

The exact mechanism needs authorization-boundary design; possibilities include a dedicated repair operation/capability or reuse of trusted last-complete classification where that evidence is cryptographically and transactionally bound.

Regression coverage

Add hosted-provider integration coverage for:

• authorized repair of an existing malformed-frontmatter record;
• denial when an unrelated scoped application attempts to claim the record by changing its type;
• denial when the repaired after-image remains malformed or outside scope;
• byte/revision preservation after rejected repairs;
• successful ordinary updates after repair;
• behavior when no trustworthy prior classification exists;
• records created by legacy/import/mirror paths rather than only structured operation input.

Product impact

Plain-text records are routinely edited incrementally and may arrive from older clients, imports, sync, or manual filesystem changes. Intake prevention is valuable, but it cannot replace a safe recovery path for malformed records that already exist.