CheckoutView.swift's addressSection showed the literal string "Casa"
as the address name/label regardless of which address was actually
selected — only the street/detail line below it (customerAddressLabel)
was wired to real state. Added customerAddressName, preferring
selectedCustomerAddress?.label then appState.address.display, matching
the same fallback pattern already used for the detail line.
Explains why the delivery fee specifically never changed while other
address info (label, street) updated fine after the previous fix:
AddAddressFormView only sets latLong when the CEP lookup happens to
return coordinates (AddAddressFormView.swift:141-146) — plenty of saved
addresses have none. Without coordinates the backend can't distinguish
that address from the previous one, so the fee (and, in Checkout,
checkoutAddressWatchKey itself) never actually changes, without any
error surfacing since it likely falls back to some default fee instead
of rejecting.
Added LocationService.geocodeAddress(street:number:neighborhood:city:
state:zip:), a thin CLGeocoder wrapper, and call it in both
CartView.refreshDeliveryFee and CheckoutView+Logic.
validateDeliveryAddressIfNeeded whenever coordinates are missing,
persisting the result back into appState.address so it doesn't need to
re-geocode on every subsequent check.
CustomerAddress.id is genuinely optional (Services/ApiModels.swift:46) —
some address book entries have no id. AddressesView.selectAddress sets
appState.address.selectedId = address.id directly with no fallback, so
picking one of those addresses leaves selectedId nil. The matching
cascade in both CartView and CheckoutView+Logic then skipped straight to
a label match, which silently collides whenever two addresses share an
empty or duplicate label (common for unnamed entries), and finally fell
back to addresses.first — always redisplaying whatever's first in the
list regardless of what was tapped, with no error surfaced anywhere.
Coordinates are set immediately and reliably at selection time and are
far less likely to collide than a label. Checkout already had a lat/lng
fallback but ordered after the weak label match; promoted it ahead of
label matching in both files, and added the same fallback to Cart, which
didn't have one at all.
Cart's delivery fee and Checkout's address validation both fetched the
customer profile without forcing a cache refresh (2h TTL), then let that
possibly-stale address book unconditionally overwrite the just-picked
appState.address coordinates before building the fee/validation payload.
Result: changing the address on Home didn't reliably move the cart's
delivery fee, and Checkout's 'Alterar' could silently revert to the old
address when the stale coordinates made the backend report it as not
served.
Force-refresh the profile fetch and only use it to fill genuine gaps in
appState.address, never to override a live user selection.
Terms and Privacy screens now fetch the real PediFoods customer PDFs
from the backend instead of showing static placeholder text. Also
surfaces both links on the Profile screen below the version label,
not just during registration.
