fix(caps): correct capability v3 byte order and lock securebits

[noeljackson]

Summary

Fix two bugs in the Linux capability v3 handling:

1. Swapped data[0]/data[1] in capget/capset

Per the kernel capability v3 ABI, the __user_cap_data_struct array uses:

• data[0] = capabilities 0-31 (low 32 bits)
• data[1] = capabilities 32+ (high 32 bits)

The previous code had these reversed in get_caps(), set_caps(), and the error path of capset(). This caused capabilities above 31 (e.g. CAP_MAC_OVERRIDE=32) to be placed in the wrong position and capabilities 0-31 to be shifted up, making capset(2) fail or silently apply wrong capability masks.

2. Unlocked securebits in set_keep_caps()

set_keep_caps() only set SECBIT_NO_SETUID_FIXUP (bit 4) without locking it. A process could clear the securebit before the capability drop sequence completes, defeating the purpose of preserving caps across UID changes.

Now sets SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED | SECBIT_KEEP_CAPS_LOCKED (4 | 8 | 32 = 44) to make the securebits immutable.