Correct GST state selection for walk-in and named customers

[sridharkalaibala]

A walk-in sale with an empty customer state could be classified as interstate because the sale writer compared the empty string directly with the branch state. Equivalent state names and GST codes could also disagree across calculation and receipt paths.

Use the branch state for walk-ins, the configured default customer, and customers without a state. Named customers with a different state receive IGST; same-state customers receive CGST/SGST. Resolve equivalent GST codes and names consistently in the sale calculation and legacy receipt reconstruction. Persist the resolved customer state and calculated components with the sale; preserve existing recorded components on reprint.

Validation: 314 focused API tests passed across sale service, repository, GST state selection and receipt components. Includes blank states, the configured default customer with a stale different state, state names/codes, interstate and same-state totals. Local pre-push checks are also run before pushing.

Sync: customer_state, legacy GST fields and tax_components remain in the existing branch-scoped sales document, whose lane is configured in POS, Gateway and the realtime sync agent. No new fields, collections, print commands or migration are introduced. Each originating API computes and stores the breakdown; cloud and other tills consume those saved components. Live cross-device/reconnect verification has not been performed. Existing historical records are not rewritten.

Merge develop first, then include in the existing develop-to-main promotion. No public installer release.

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.