Refactor and test version comments

[theosanderson]

Currently versionComments are implemented in a pretty confusing way for developers:

• versionComments can either be stored as a metadata item called versionComment or as a column called versionComment
• For revisions the first approach is used
• For revocations the second approach is used

Instead we should just use one approach :)

[anna-parker]

Just for some background I did this as a workaround because revocations have an empty originalDataColumn in SequenceEntriesTable and are not sent to preprocessing (they are filtered out in fetchUnprocessedEntriesAndUpdateToInProcessing) - so their processedDataColumn in SequenceEntriesView is always empty in the current set up. The versionComment field for revocations is therefore a special case as it is generated from user input but cannot (directly) be read from the processedDataColumn like other user-input metadata fields. As a workaround I chose to add the versionComment field in its own column and merge this column with the processedDataColumn when retrieving metadata.

Other options could be:

• Add the revocation versionComment to the originalDataColumn instead of a custom column and again have a custom merge that handles revocations and revisions differently when we get the data from the backend e.g. in the get-released-data call. -> same level of complexity
• Add the revocation versionComment to the originalDataColumn and send revocations to preprocessing so that the versionComment ends up in the processedDataColumn -> will probably require some prepro changes
• Add the revocation versionComment to the originalDataColumn and update the processedDataColumn with the contents of the originalDataColumn automatically for revocations. -> I think this is the best approach I can think of

[anna-parker]

@theosanderson-agent can you draft a PR where we attempt to solve this difference in implementations with the last suggestion?

Add the revocation versionComment to the originalDataColumn and update the processedDataColumn with the contents of the originalDataColumn automatically for revocations. -> I think this is the best approach I can think of

You should then also write a migration to copy over the contents of the existing versionComment column to these new metadata jsonb columns and delete that column in the db

[theosanderson-agent]

I've drafted a PR implementing the suggested approach: #6198

Approach: The revocation versionComment is now stored in originalData.metadata instead of the dedicated version_comment column. The database view automatically constructs joint_metadata for revocations from originalData, so the versionComment flows through the same path as revisions.

Key design choice: rather than inserting into sequence_entries_preprocessed_data (which would be tied to a specific pipeline version), the view constructs the metadata directly from originalData for revocations. This means the versionComment survives pipeline version changes without needing to reprocess revocations.

The PR includes a migration (V1.26) that moves existing version_comment values into originalData.metadata and drops the column. Code compiles and lints cleanly; full test suite needs PostgreSQL infrastructure to run.