fix github issue #121 - correct bitmap stride in QR code generation

[munzzyy]

Fixes #121.

encodeAsBitmap() in SocialImageUtil.kt builds the pixel array using w/h, the actual dimensions zxing's MultiFormatWriter hands back from BitMatrix, and fills it with offset = y * w per row. But the call to bitmap.setPixels() right after passes width (the size that was originally requested) as the stride argument instead of w.

Those two aren't guaranteed to match. QR codes only come in fixed module counts, so MultiFormatWriter.encode() can return a BitMatrix sized slightly differently than what was asked for. Whenever that happens, setPixels() reads each row starting width entries apart in the array while the data is actually laid out w entries apart, so every row past the first is read from the wrong offset. The result is a bitmap where all but the first row of the QR code is shifted, which is exactly the "doesn't render any data" / unscannable symptom in the issue.

Changed the stride argument to w so it matches how the array was actually populated.

Couldn't run this on-device (no Android SDK/emulator in this environment), but the bug is a plain array-indexing mismatch and the fix is checkable by inspection: pixels is written with row stride w, so setPixels needs to be told the row stride is w too. There's no existing test target for this class in app/src/main, so I didn't add one - happy to if there's a preferred place for app-module unit tests here.

[n8fr8]

Thanks for the fix... I think #121 is actually something else (the image hadn't been uploaded yet to ipfs storage, and so there wasn't a proper URI in the QR code, jus as hash:foo value), but this is still a good bug find anyhow.