Partial answer: The xmodmap mapping actually works correctly. As xev shows, you get keysym 0xffbe which is F1, as it should be.
So the question is (1) why it still changes brightness and (2) why it returns the keycode 232 (for KEY_BRIGHTNESSDOWN) instead of the one for the F1 key (67).
For (1), I suspect Ubuntu runs something by default the reads directly from /dev/input instead of processing X events, and this is processing the key no matter what xmodmap says. You didn't say which desktop environment you run (Gnome?). You can look with lsof for a process that directly reads the /dev/input/eventX source (you got the number X from evtest, numbers can change across boots). You can also test this theory by running evtest --grab /dev/input/eventX: This will make evtest the exclusive program to process the events, so when you press Fn+F1, it should still show KEY_BRIGHTNESSDOWN, but the brightness of your PC/Laptop screen should stay the same.
As for (2), googling the brand name shows it's a Bluetooth keyboard. This means it's likely a HID device. You can debug the by looking at dmesg to identify the corresponding hidraw device file and the bluetooth identifier. Then do
mount -t debugfs none /sys/kernel/debug
as root, and have a look at sys/kernel/debug/hid/*/rdesc for the correct device (look at available subdirectories). If you can't make sense of it, put it in a pastebin and edit the question with the link. Also, dump raw HID events using hexdump -C /dev/hidrawX, pressing Fn and F1, F2 etc several times. That should give you an idea why the kernel translates this the way it does.