Play will reject the next release: adblock native libs are 4 KB aligned

Google Play [rejects apps targeting Android 15+ whose native code is not 16 KB
aligned][1] since 1 November 2025, so the next release is blocked independently of
the target SDK bump. `libadblock-client.so`, shipped through
`com.github.Edsuns.AdblockAndroid:ad-filter:v0.9.1`, is 4 KB aligned in all four ABIs.

Android 17 already surfaces it at install time, naming the library and telling the
user to contact the developer ("This app is incompatible with 16 KB mode. ELF
compliance check failed"). Screenshot available if useful.

## Evidence

`LOAD` alignment read out of the ELF program headers of a universal APK built from
current `dev`:

| ABI | LOAD alignment |
|---|---|
| arm64-v8a | 4096 |
| armeabi-v7a | 4096 |
| x86 | 4096 |
| x86_64 | 4096 |

16384 is required. Reproduce with:

```
unzip -o app.apk 'lib/*' -d out
$ANDROID_HOME/ndk//toolchains/llvm/prebuilt//bin/llvm-objdump -p \
out/lib/arm64-v8a/libadblock-client.so | grep LOAD
```

## Patching the headers is not a shortcut

Tools exist that rewrite `p_align` in place, and I checked whether that would be
enough here. It is not. ELF requires `p_vaddr ≡ p_offset (mod p_align)` for loadable
segments ([elf(5)][2]), and the second `LOAD` segment of every ABI breaks that
congruence at 16 KB — it is off by exactly 0x1000, the signature of a 4 KB layout:

| ABI | `p_vaddr % 16K` | `p_offset % 16K` |
|---|---|---|
| arm64-v8a | 0x1878 | 0x878 |
| armeabi-v7a | 0x27fc | 0x17fc |
| x86 | 0x2bec | 0x1bec |
| x86_64 | 0x39a8 | 0x29a8 |

Bumping `p_align` alone would produce a file that violates the spec. It would likely
pass a static scan while still being rejected by the loader on a real 16 KB device,
which is worse than the current state. The library has to be relinked.

Also worth noting: AGP 8.5.1+ only fixes zip alignment inside the archive, not the
alignment inside the `.so`, so a toolchain bump on this repo alone changes nothing here.

## The fix, and where it has to land

The upstream library carries its own native sources (`adblock-client/CMakeLists.txt`),
so the change is one line — [per the official guidance][3], either build with NDK r28+,
which aligns to 16 KB by default, or for r27 and lower add:

```cmake
target_link_options(adblock-client PRIVATE
"-Wl,-z,max-page-size=16384" "-Wl,-z,common-page-size=16384")
```

The catch is that it has to land in `Edsuns/AdblockAndroid`, which has had no commit
since August 2021 and currently has open issues reporting that JitPack can no longer
clone it. So the practical decision is yours and it is about the dependency, not about
this line: fork and publish, vendor the sources into this repo, or move to a different
engine.

Happy to prepare a PR for whichever route you pick — I did not open one because
pointing the dependency at a fork of mine is not something a maintainer should have to
accept unasked.

Filed separately from #231 because it is independent of the edge-to-edge work and
blocks the same release on its own.

[1]: https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html
[2]: https://man7.org/linux/man-pages/man5/elf.5.html
[3]: https://developer.android.com/guide/practices/page-sizes#build