SUCCESS!!! I used @Miek's Python script to generate the hash for my instrument's serial number:
(base) byrd:test max$ ./4263B_hash.py MY40103486
Hash: 0x21 0x44 0x56 0x41 0x28 0x56 0x73 0x67
I then programmed 4 longwords, starting at offset 0x020. This is actual address 0x1e0040 because of the last address bit fiddle described. In decimal, this is 1966144.
The three longwords are made up of:
0: 0x31 0x00 hash0 hash1
1: hash2 hash3 hash4 hash5
2: hash6 hash7 0x30 0x30
The first byte in word 0 is the ASCII '1' character that enables the option, the second byte is what I originally read from the EEPROM. The last two bytes in word 2 are the leading zeros in the code for option 2, which I enabled back in 2018.
The actual commands I sent, using Interactive IO from the Keysight IO library suite, were:
:TEST:MEM:ADDR 1966144
:TEST:MEM:LONG 822092100
:TEST:MEM:LONG 1447110742
:TEST:MEM:LONG 1936142384
I read the same addresses back, using the commands:
:TEST:MEM:ADDR 1966144
:TEST:MEM:LONG?
:TEST:MEM:LONG?
:TEST:MEM:LONG?
and verified the contents had changed as expected. I took a deep breath and power-cycled the instrument - and option 001 was there! The extra measurements appear on the menus as expected. Not having a transformer test fixture, I am not able to verify their function yet.
I have a copy of the original installation note for end-user installation of this option. Importantly, this does NOT say that the unit needs to be recalibrated after enabling the option (it does for option 002, though obviously only at the 20kHz setting. In my case, only the lowest capacitance ranges were out of spec before adjustment. Looking elsewhere in the dump file, I can see there are 'new' calibration factors, which look like doubles, in many places. For example, at offset 0x3f0, 0x3f80000000000000 has become 0x3f800019bc0c8cc3.)
I think @Miek qualifies for the hacker's Golden Pizza award for this - well done!