2.0.4

Start against a database the enterprise overlay has migrated (#27)

The overlay ships its own migrations for its own tables. Once one has run,
the history table records a version the open source build has no file
for, and Flyway's default answer to that is to refuse to start:

    Detected applied migration not resolved locally: 20260908203708.

That strands anyone whose enterprise trial ended, and anyone pointing both
editions at one local database — both editions default to the same
database name on the same port.

Flyway now ignores applied migrations this build does not own, both the
"missing" kind (older than its newest migration) and the "future" kind
(newer than anything it has); naming a pattern replaces Flyway's default
of ignoring future ones, so both are listed. Nothing is lost by it: an
overlay migration only ever touches overlay tables, which this edition
never reads. A changed checksum or a failed migration still fails
validation as before, and the test proves both halves.

Signed-off-by: Josh <ascetik@gmail.com>

2.0.3

Render report sections in the DOCX, and make them an enterprise featu…

2.0.2: Let testers arrange findings by hand, and report in that order (#25)

The assessment screen and the generated report now both follow a single
display order, and the tester can rearrange it by dragging rows.

Severity is applied when a finding is created rather than when the list is
sorted: a new finding (or one carried forward, or one whose severity changes)
is placed after the last finding that is at least as severe. An untouched
list therefore still reads Critical to Informational, but anything moved by
hand stays exactly where it was put — including the occasional High placed
above a Critical, which the old severity-first sort silently undid in the
report. A one-off migration renumbers existing findings the same way; on the
dev database it reproduces the old report order for every assessment.

A "reset to severity order" action appears only once something sits above a
more severe finding. Reorders broadcast to other viewers of the assessment
as before, and the live refresh is held while a drag is in progress.

Also on the finding list: each row's left border takes its severity colour
(the accent when selected), and the form panel no longer draws a scrollbar.

Signed-off-by: Josh <ascetik@gmail.com>

2.0.1: Publish one version string, not two (#15)

The release tag is both the Docker Hub tag and the version the UI footer
shows, so the two have to agree. Releases are tagged v2.1.0 by convention,
but 2.0 is already on Docker Hub unprefixed — publishing both forms leaves
anyone pinning FACTION_VERSION guessing which one their release used.

Strip the leading v once, where the tag is computed, so it reaches the
registry and APP_VERSION in the same form the footer already renders.

Also point the Dockerfile's comment at release.yml; release-deploy.yml is
not a file in this repository.