Fixture + evidence: JianYing 9.0.0 Windows opens a tool-written plaintext draft, encrypts the legacy mirrors on close #148

The capture (produced with capcut fixture, media excluded, home paths / emails
/ device identifiers redacted) is committed in the accompanying PR as
test/fixtures/jianying-9-0-0-windows/.

Environment

app         剪映专业版 (JianYing)
version     9.0.0
OS          Windows 10.0.19045
draft store %LOCALAPPDATA%\JianyingPro\User Data\Projects\com.lveditor.draft

What was done

1. capcut-cli 0.29.0 created a draft and wrote into it (add-text, then a text
   template). A human acceptance check then closed the project and opened it in
   the app: the added text segment was present on the timeline and editable.
2. The project was captured with capcut fixture after that open.

What the capture shows

So on this build:

• the app accepted a plaintext, tool-written primary and kept it plaintext;
• it converted the legacy mirrors to encrypted blobs;
• the CLI still reads the project (canonical draft_info.json), and never writes
  into the encrypted mirrors.

Two further observations from the same machine:

• An app-authored project on this build is a plaintext draft_content.json with
  no draft_info.json or template-2.tmp at all (12517 bytes, 5 tracks, read
  fine by capcut diagnose). The 11.4.0-macOS note — "the primary file name has
  been draft_info.json since 6.0" — therefore does not hold for this build.
  That folder is the owner's work, so it is not attached; the consequence is
  recorded in docs/version-support.md.
• A segment in the captured draft has target_timerange {"duration":3000000}
  with no start and no speed. The app renders it normally; capcut segments -H printed NaN:00NaN / undefinedx. Reported separately (issue segments renders NaN for a segment whose target_timerange has no start #147).

The question for the maintainer

The lv >= 6.0 write guard is currently refuse, justified by the
encrypted-draft era. This capture is the same shape of evidence as the JianYing
11.4.0 macOS row, which is labelled "plaintext drafts accepted on open — generation
is not blocked" while the guard stays conservative. Two possible follow-ups, both
deliberately left out of the PR so the decision is yours:

1. Add the row (with the fixture) and leave the guard exactly as it is — what the
   PR currently does.
2. Narrow the refusal for projects whose primary is plaintext and readable
   (draft_info.json present and parseable, mirrors either absent or unreadable
   encrypted blobs), keeping the refusal for app-authored fully-encrypted
   projects. That would let a plaintext pipeline write its own drafts without
   --force-write while still refusing a draft the CLI cannot read at all.

--force-write does work on this build today, and the app opens the result — but a
guard that has to be overridden for a normal workflow is worth revisiting once a
second build confirms the behaviour. If it helps, the same capcut fixture run on
another 9.x build would settle it.