Bridge 0.9.7

Bridge 0.9.7 lets Stage 6B's location engine consult completed
translationCore Word Alignment as location evidence, closes three defects
a follow-up review found in that change before it ever reached a release,
and removes a pointless Edit→Save round-trip before a manually written
correction proposal can be applied.

Companion storage moves from schema v14 to v15 (additive; a v14
database opens and migrates automatically, and every pre-existing record
reads back unchanged). Correction verification remains
correction-verification-policy-v2.

Highlights

• Stage 6B now scores a WORD_ALIGNMENT evidence component from any
  same-verse translationCore alignment group already marked completed,
  at the same weight (0.65) the existing HUMAN_PRECEDENT component
  uses — a source verse a translator has already aligned to its target
  now helps Stage 6B locate a QA finding correctly, rather than that
  alignment work going unused by location search. Cross-verse alignment
  and any embedding-provider direction remain future work under #54.
• Fixed a casefolding bug that could silently drop this new evidence for
  any target text containing a cased word pair (most scripts with
  separate upper/lower case) — word/occurrence identity now compares
  exact NFC text, never casefolded, matching how occurrences are counted
  everywhere else in Bridge.
• The new alignment-evidence dependency edge is now written in the same
  transaction as the location run it protects, closing a crash window
  that could otherwise leave a run permanently immune to invalidation.
• A verse-bridge alignment group (e.g. one spanning "PHP 1:2–3") is now
  actually excluded from this evidence, matching what was already
  documented — previously nothing enforced it.
• Alignment state changes made through a scripture edit, a correction
  application, or completing an alignment now all correctly refresh the
  memo Stage 6B's invalidation check compares against — previously two of
  those three paths could leave a just-published, still-correct location
  run spuriously marked stale on the next time the project is opened.
• A manually written correction proposal is now usable immediately —
  "Review application" no longer requires an Edit→Save round-trip first.
  That round-trip was already unchecked self-review with no distinct
  reviewer required, so this removes a step that added no real review,
  not a safety control. Existing proposals stuck in this state are
  repaired automatically, in place, the next time they're opened.

Safety properties retained

• No Scripture is changed without explicit human Apply confirmation.
• A wrong or unresolved Word Alignment match never becomes location
  evidence — anything but exactly one clean match on both the source and
  target side is dropped entirely rather than guessed at, costing that
  one alignment group's contribution, never a whole search.
• Nothing in this release ever writes to translationCore's own alignment
  data or completion markers; Bridge only reads them.
• Every automatic reseed of a stuck correction proposal's review status
  is attributed to a MIGRATION actor, never the named human reviewer,
  and is fully audited as its own event.
• The optimistic-concurrency revision a reviewer's session has cached
  is never invalidated behind their back by an automatic reseed.
• No weight, threshold, or scoring formula changed for any existing
  evidence component; the Stage 6B golden fixture is byte-identical.

Known limitations

• Cross-verse Word Alignment evidence and any embedding-provider-backed
  location matching remain future work (#54 follow-on).
• The author-≠-reviewer distinction for correction proposals is
  deliberately not built yet; a human-authored proposal is approved by
  its own author today, same as before this release, just without the
  Edit→Save ceremony. A dedicated reviewer field is planned for the
  #74–#81 team-workflow milestone.
• The Windows installer is unsigned and may show a SmartScreen warning.
• Windows x64 is the verified target; macOS and Linux remain unverified.
• Installed acceptance Cases A–D (Tamil negation, NFC/NFD equivalence,
  the Stage 9B.4 correction loop, and Greek/Hebrew source safety) were
  not run before this release was published — see
  docs/ACCEPTANCE_TEST_GUIDE.md and docs/V1_1_UNICODE_ACCEPTANCE.md.

Windows installer

Bridge_0.9.7_x64-setup.exe (attached below), built by this repo's own
CI (.github/workflows/release.yml).

SHA-256: CDB662CF6211988AC6637D6FE34FFBF06C1037959CAA6CA122EBB389A331D78F

Full verification numbers and build details are in
docs/RELEASE_0.9.7.md.