If one of those is HP, only 1/10th of Agumon's HP is used

This 1/10 uses integer division too, right? This can lead to different results in very specific edge cases, which should be clarified and (IMO should be) tested. The current edge cases doesn't specifically test for this part.

Enjoyed this kata.

Test cases looks really well done, with fixed, boundary and randomised tests.

Took me a while to understand the requirements, and initially I thought there was not enough information in the description to solve the kata.

However I just had to read through it carefully to piece together the algorithm.

Perhaps the description could be improved to work through an example of calcuating the full score for an individual candidate champion? But perhaps understanding the requirements is just an intrisic part of the difficulty for this kata.

I think difficultly wise I'd go for 4kyu based on "Understanding intricate business requirements".

Why go to all this trouble when you can just write

switch ( true ) {
  case /[a-z]/i.test(input): return "letter";
}

?

null matches null and nothing else.

Is this a test on the pattern or on the input?

Ie, can I skip ( almost ) all pattern matching after a pattern of null, or on an input of null ?

[a] pattern matches if pattern[matchesSymbol](input) is truthy

Is pattern[matchesSymbol] actually an invisible property of the pattern argument that will be passed to the solution function by testing? This is not clear - pattern is not really defined as an ( odd-indexed ) argument to the solution function ( some strategically placed backticks would help ), no examples are shown for pattern[matchesSymbol], and it's really only mentioned once, seemingly in passing, after which the focus is immediately moved to something completely different.

Some more explanation, and maybe an example, would be nice there.

( Why do we need to work with pattern[something] instead of just with pattern ?!? )

How does a primitive value match to an Object ?

Treating constructors as normal functions introduces all sorts of weird behaviour, including Errors that have to be caught and ignored.

Encoding is Boolean as Boolean seems pretty at first glance, but this is not how JS contructors work, and the consequences are dire. Unfortunately, there is no way to distinguish constructors and non-constructor function, but surely some indication to test for either presence in the prototype or return value when applied can be defined, and would make this part of testing much more elegant.