Using "mini" to mean a subset of the language rather than a version for small systems has precedent. For example in the Perl community, miniperl is a subset of Perl. It's mostly used to bootstrap builds of the full language, but in theory can be used separately as a restricted programming language. It's also the name of a module, ExtUtils::Miniperl, for Perl (https://metacpan.org/pod/ExtUtils::Miniperl) that builds miniperlmain.c and perlmain.c files to bootstrap the compilation of the language system. This is not to be confused with the Raku project on Github called "miniPerl" (https://github.com/grondilu/miniPerl) which compiles subsets of Perl via the Lambda calculus to JavaScript output.

I'd personally pretty much always expect "mini" or "r" (as in "rperl", a restricted subset of Perl with C++ connections) versions of a language to be restricted subsets for some purpose (rperl's is to give away flexibility for performance while maintaining a good portion of the original language).

I've seen an "e" or "emb" prefix or a "small", "tiny", "micro" or "µ" (or "u") prefix to mean a small toolchain version several places, like SmallC or uclibc or Mikroe's mikroC (https://www.mikroe.com/mikroc). It wouldn't surprise me to see a "nano" version of a language tool either. Sometimes these are subsets as well, but to fit the size constraints of the target rather than for constraining the input for its own sake.