fix: correct .0 octet truncation in PaddedStringToIPV4

[a11ensu]

Description: Fixes a regression where IPv4 addresses containing a .0 octet are truncated when read back from the SQLite store, producing invalid values in the IPAM CR status.
PaddedStringToIPV4() (pkg/utils/utils.go) un-pads stored addresses using strings.TrimLeft(octet, "0"). For an all-zero octet, "000" is stripped to "" instead of "0", so any address ending in (or containing) a 0 octet is corrupted on the read/write-back path — e.g. 10.65.82.0 (stored as 010.065.082.000) is reconstructed as 10.65.82., and 0.0.0.0 becomes .... This surfaces as IPStatus[N].ip: Invalid value: "10.65.82." on network-boundary addresses. The regression was introduced in d06b176 (#176) and shipped in v0.1.13.

Changes Proposed in PR:

• Rewrite PaddedStringToIPV4() to parse each octet numerically with strconv.Atoi and reprint it, so "000" -> "0" and "082" -> "82".
• Return the input unchanged for non-4-octet or non-numeric input, so IPv6 addresses and malformed strings pass through untouched (previous behavior preserved).
• No DB schema or storage-format change; stored padded values remain valid and are now decoded correctly (no data migration required).
• Add IPv4 and IPv6 unit tests in pkg/utils/utils_test.go covering .0 boundaries, 0.0.0.0, non-zero octets, pad/un-pad round-trips, and IPv6/malformed pass-through.

Fixes
NA

General Checklist

• Updated Added functionality/ bug fix in release notes
• Added examples for new feature — N/A (bug fix, no new feature)
• Updated the troubleshooting guide or documentation — N/A (internal decode fix; no user-facing config change)

CRD Checklist

NA (no CR schema change)