Is partial digest recognition possible?

There are a lot of problems here, but I'll focus on ones that jumped out at me. The attempt to scramble the XOR ordering is doing basically nothing at all. First of all, it's almost 100% dependent on information that the attacker knows. Using the raw key length adds some entropy, but extremely little. Even leaving aside that the single fast hash is inadequate for passwords and therefore the "key" is probably a pre-hashed or random input of a known length, there are few enough possibilities that an attacker can simply try them all.

It is entirely possible for many, even most, codex values to never be used at all. For example, if the multiplier is even, then at least half of the codex is never used, since any even number shares a common factor (2) with 128. In fact, in the not-that-unlikely case that the multiplier is an exact multiple of the codex length - e.g. if the text is exactly 128 bytes long (the max), or the text is 56 (or some other multiple of 8) bytes long and the key is 16 bytes long (the shortest allowed value, and a very common length of random keys: 128 bits) - the result is disaster. Every single ((i + 1) * multiplier) % codex.length will return 0, so every single byte of the plaintext (array) will be XORed with the same value (the first byte of the hash digest).

Even in the case where the key length is totally unknown and the message length is not a multiple of 128, an attacker can probably find repeats more often that every 128 characters knowing only the message length. At most, the cycle of repeats will have a length of 128 / GCF(128, text.length), where GCF is the greatest common factor function. So if the text length is even, that cuts the cycle length in half (by necessity, cutting out half the codex, as mentioned above). If the text length is a multiple of 8, that cuts the cycle length by 8x (down to merely 16 at most), eliminating 87.5% of the codex entropy... and that's a best-case outcome, assuming the key length is relatively prime with the codex length (which is to say, assuming the key length is odd).

For each such repeat, an attacker who can predict the locations of the repeat can XOR any two corresponding bytes of ciphertext together to mask off the codex byte and get the XOR of the two plaintext bytes. If the attacker knows the value of any such byte, they can immediately decrypt all other locations where that codex entry was used. Even without knowing the values, it might be possible to perform a frequency analysis on the repeats, if you have enough of them, to determine likely plaintext values. Such an analysis would rely on the fact that certain characters occur more often than others, in predictable ratios, in text. The fact that the XOR between different characters would be known makes it even easier, and would compensate somewhat even if there were a low number of repeats for any given codex entry.

This sort of problem - where a failed attempt to reliably avoid one problem ended up introducing a potentially catastrophic failure mode - is very common in cryptography, especially among amateurs. Cryptography is very hard, especially if you don't even start from the known failures of past attempts.

With that said... I'm not even a number theorist or math major, much less a cryptographer; most of my math knowledge is merely what was required for a CS degree. Consequently I expect tons of people can and will spot this issue (and more knowledgeable ones will spot many, many more) if they bother to look.

But wait, there's more!

During the XOR step, you're combining each byte of the message (text) with a single byte of the codex (hash of the base64 of the key), to produce ciphertext. However, while the message bytes may by any value in the range 0-255 (0x0-0xFF), the codex is generated from a hex-encoded string. Each byte of the codex can only be one of 16 values (0-9,a-f, encoded as decimal 48-57,97-102). Thus, for every byte of ciphertext, there are only 16 possible bytes of plaintext (and the attacker knows what they are). This makes even simple brute-forcing short parts of the message possible; especially for commonly-used characters that are far from any other common character in the character set (such as space), regardless of your key or multiplier. This is a catastrophic weakness, enabling cryptanalysis of even relatively short messages that avoid the multiplier-introduced problems, without any form of "crib" (known plaintext or message format).

Some thoughts:

• If you really want to do this, why not just use a stream cipher (with no IV/nonce or integrity) or a block cipher in ECB mode? Neither is safe, but they're much, much safer than this. All three approaches have the problem that two identical messages encrypted with the same key will have the same ciphertext. Your cipher shares another problem with the stream cipher (bit-flipping attacks are trivial) but even badly broken stream ciphers don't have the short cycle problem, much less the 4-bits-entropy-per-byte problem. ECB has the problem of leaking structure through repeats of blocks, but it only applies to blocks where all 16 bytes (if you use a modern block cipher like AES) are the same between block-boundary-aligned blocks.
• Alternatively, why can't you store an IV and authentication/integrity tag? The messages are variable length to start with.

Simple design or code quality problems, that don't necessarily impact the security of the cipher:

• The code will throw if the key contains any multi-byte characters, as atob doesn't allow those.
• Why are you calling atob anyhow? It isn't needed.
• The code may throw if the text contains any multi-byte characters (on the step where the ciphertext is decoded as UTF-8), as not all byte sequences are valid UTF-8.
• You didn't encounter this problem in your testing because you never set or clear the most significant bit, and all byte sequences where the MSB of each byte is unset are valid UTF-8 (that's literally just ASCII), but you never state or validate this precondition.
• Even if the code doesn't throw, if the text contains any characters that encode as multiple bytes in UTF-8, you might get the string length to appear within bounds (that is, text.length <= 128), but after encoding as UTF-8, the length of array could exceed 128 considerably (a single Unicode character could take 3, maybe more, UTF-8 bytes), guaranteeing the presence of repeated use of codex values even in the best case.
• You compute a value, pads, and then never use it.
• A cipher that only "works" on up to 128 bytes at a time is nigh-worthless unless it can be used in a block-cipher mode of operation. Presumably this limit is to try to avoid repeats of the codex value, but at what cost? You say classroom notes, but this can't even hold a tweet.
• A cipher that can't do any work until it knows the final message length is completely unsuited to use anywhere performance is needed, since that is achieved through streaming data. Of course, the previous point largely renders it moot.