What is the "best" way to encode a text so it can be stored somewhat securely in a text file and later be de-coded so the text can be read (preferably only by the owner)
This is literally exactly what "encryption" is. The best way to do this is to use a secure cryptographic cipher (a function that takes as input a key and some plain-text data and emits an incomprehensible "ciphertext", or that takes a key and some ciphertext and emits the original plain text). The key (at least, the one used for decryption; in some ciphers you use one key for encryption and a paired but different one for decryption) must be kept secret and must not be predictable by an attacker, but most ciphers (if used correctly) can encrypt and decrypt data far, far longer than their key. For example, I have a 2TB (2000000000000-byte) hard disk encrypted using a 256-bit (32-byte) key.
The question of what cipher is "best" depends on a lot of things, but right now the most widely-trusted cipher is called AES (Advanced Encryption Standard). AES by itself can only encrypt small blocks of data (exactly 16 bytes), so it is combined with a block cipher mode of operation and sometimes a padding that lets you re-use the same key with a (nearly) unlimited number of blocks and with data that isn't an integer multiple of the block size. In this way, I can have some secret data (such as a password file) of essentially arbitrary length, and it is totally unreadable to anybody who doesn't have the right 16- or 32-byte key (which in practice can be derived from a password, though most real-world passwords are far more predictable than a proper encryption key so this does make it weaker)
Any decent password manager (including the multiple available commercial and/or open-source ones) use a "master password" or "master key" to protect the stored passwords. This master secret is used to encrypt and decrypt an encryption key (which is totally randomly generated and never stored in plain text, but is stored in encrypted form along with the encrypted passwords), and the encryption key is used to actually encrypt and decrypt the passwords (which, again, are never stored in plain text). The master can either be a key that is stored in some device (like a Yubikey or flashdrive that must be entered before decrypting the passwords), or a password itself that is turned into a cryptographic key by running it through a key-derivation function (essentially a very computationally expensive salted cryptographic hash function).
The reason for this additional layer of indirection (master key wrapping the encryption key which in turn wraps the passwords, rather than just using the master key to wrap the passwords) is so that you can change the master or have multiple master secrets (say, a password and also a recovery key stored on a hardware token) without needing to re-encrypt anything except the encryption key. This also makes it easier to handle password sharing between users (where one user wants to allow another user to see some of their passwords, but not all), if you ever desired to add that feature.
Unfortunately, Automate doesn't support any cryptographic ciphers (and the hash functions it supports are old and deprecated, although you can build a KDF out of those if you have to). Short of re-implementing something like Blowfish or AES using Automate - which you definitely should not do - that means the language is simply not suitable for any app that needs to handle sensitive data.
You seem to have a few false beliefs about security which I'm going to try to clear up here.
that means that the program will be open source, so I think it's impossible to make it completely secure because anyone can see & modify their local version of the code
There are lots of extremely secure open-source tools for storing secret data. A few examples: Gnu Privacy Guard (GPG), TrueCrypt/VeraCrypt, OpenSSL, numerous email clients with support for the OpenPGP and/or S/MIME standards like Thunderbird, etc. The key difference between all of these programs and your idea is that they all use actual encryption.
they need both the code & someone else's save-file to compromise the security, and realistically then it's already game over for any security program
This is very, very false. A crucial requirement of good encryption is that even if the attacker has the full ciphertext (encrypted data, such as your password save file, and any data typically stored along with it such as a message authentication code and the initialization vector for the encryption) and knows the full details of the algorithm used to encrypt it (such as AES-256 in CBC mode with that known IV and using PKCS5 padding, as implemented in a particular version of the open-source "OpenSSL" tool), the attacker still should not be able to decrypt the data without a brute-force attack on the key, which can be made long enough that such an attack is totally impractical (we're talking "using every processor in existence on earth, you still wouldn't finish before the heat death of the universe" levels of impractical, here). That is what people mean when they say "obscurity is not security"; if your system is secure only so long as the attacker doesn't know exactly how it works, it actually just isn't secure.
I'm not aiming for Bank-level security
Aim higher. Banks often don't actually use very good cryptography (or security in general), by modern standards. It would be harder to get into my password manager's vault than into my bank account, because my bank doesn't permit the use of passwords that are as strong as my password manager does, and the numbers needed to extract money from my account (account number + routing number, or card number + ZIP code + CVV or PIN) are probably easier to guess or find than even the bank account password (still not truly easy, but probably easier).
I don't really trust them since I can't know what their code is doing to my passwords
like maybe it's storing them on a central server?... NO!
Some security people definitely agree with you that they don't want their password vault going to any device they don't control (such as a password manager company's server). However, I don't think you have a good grasp of the actual risks. Done right (and remember, you can verify that it's done right), the password manager company can never decrypt your vault, so even though they hold onto it they cannot peek inside. As mentioned above, even though they have the vault (the ciphertext) and obviously know exactly how it was encrypted (because it was their code that did it), they cannot decipher the contents without the encryption key, and well-designed password managers never store or transmit the encryption key (or any material used to derive it). There is still some risk, because they can try to steal or guess your master key somehow without you knowing that it's happening (for example, by trying to guess your password using an "offline" attack), which they cannot (usefully) do if they don't have the ciphertext (the vault), but it's probably a lot less risk than you thought.