All X.509v3 extension values are encoded outermost as OCTET STRING -- that's in the syntax definition -- which contains a DER encoding usually of an ASN.1 structure; but (v1) SCTList in RFC6962 is encoded using the TLS-formerly-SSL forms defined in e.g. RFC5246 section 4 applied to the list structure shown in 3.3, whose element(s) is(are) the SignedCertificateTimestamp structure shown on the same page just above that link, and thus needs to be wrapped in an extra layer of OCTET STRING.
As an example, https://stackoverflow.com/questions/69205710/modifying-extension-list-in-x509-certificate-using-openssl-in-c inserts an SCTList extension into a cert using OpenSSL -- after deleting the poison extension of the precert, which is irrelevant here. It uses a (correctly) pre-encoded value for the SCTList extension provided by the OP, which when de-base64-ed and displayed in hex for humans, breaks down as follows:
04 81 7a 00 78 00 76 00 b0 cc 83 e5 a5 f9 7d 6b
af 7c 09 cc 28 49 04 87 2a c7 e8 8b 13 2c 63 50
b7 c6 fd 26 e1 6c 6c 77 00 00 01 66 7b cf f0 d0
00 00 04 03 00 47 30 45 02 21 00 ca 24 f3 d0 85
6a a3 7b 5a d0 ab e4 f4 eb 1d 22 36 52 d3 ee b5
fb d6 4d b7 54 f6 64 86 6f d0 0b 02 20 7e 1c 0d
2b b8 b3 7a ad 1f 1c 09 6e ec 7b 98 46 39 af ca
6e 75 45 17 65 35 68 5d e7 42 d0 76 ee
04 81 7a
DER header for 'extra' OCTET STRING containing 0x7a bytes
00 78
length of SCTList
00 76
length of only SCT entry in list -- in real use the CA would get SCTs from multiple logs and put them all into one list, but you have only one DIY log so like OP you would only have one entry
00
version
b0 cc 83 e5 a5 f9 7d 6b af 7c 09 cc 28 49 04 87 2a c7 e8 8b 13 2c 63 50 b7 c6 fd 26 e1 6c 6c 77
logid
00 00 01 66 7b cf f0 d0
timestamp
00 00
length of extensions -- if nonzero would be followed by actual extension data
04 03
SignatureAndHashAlgorithm from RFC5246 for SHA256-with-ECDSA (note RFCs 8422 and 8446 changed TLS to a single combined scheme rather than independent hash and 'pure' signature components, but AFAICT that isn't applied to CT)
00 47
length of signature
30 45 02 21 ... 02 20 ...
ECDSA signature in ASN.1 DER encoding (SEQUENCE of two INTEGERs) specified in RFC3279 -- note for a 256-bit curve this will normally vary in the range 70-72 (0x46-0x48) bytes but will sometimes (rarely) be shorter
What form(s) of this information you need to give your CA software, in particular whether part(s) or all of this must be in hex, are up to your software, which you didn't identify or describe.
Also you might want to know there is a new v2 spec as of last year -- I have no clue whether, when and how it will be supported by the software you're using, but it uses data that is basically equivalent in concept but different in a number of details.