https://github.com/MariaDB/server/commit/a2367fc893d8adf9571b13f3e08d37e32226f32a

Looks OK to me.
Please amend the commit comment to explain when exactly we can have key_version==0 on an encrypted tablespace.
A test case would be nice, but given that the problem occurs during bootstrap, it may be challenging to write a test case.

commit ed7e4b68ed59fb7c34dc06625dfe378e71d1e8a7
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Tue Dec 19 16:45:10 2017 +0200

MDEV-14701: install_db shows corruption for rest encryption with innodb_data_file_path=ibdata1:3M

Problem was that crypt_data->min_key_version is not a reliable way
to detect is tablespace encrypted and could lead that in first page
of the second (page 192 and similarly for other files if more configured)
system tablespace file used key_version is replaced with zero leading
a corruption as in next startup page is though to be corrupted.
Note that crypt_data->min_key_version is updated only after all
pages from tablespace have been processed (i.e. key rotation is done)
and flushed.

fil_write_flushed_lsn
Use crypt_data->should_encrypt() instead.

I believe that this bug was introduced in the MariaDB 10.1 series only. The MariaDB 10.2 and 10.3 series should be unaffected, because they would never write the FLUSH_LSN field in other files of the system tablespace than the first one.