fix(db): pricing_packages.price_inr was seeded as rupees, treated as paise

58 of 59 rows were inserted with plain rupee-looking values (499, 999,
1999, ...) but every consumer (apps/payments/src/main.rs) treats
price_inr as paise, so PayU would have charged 1/100th of the intended
price. Confirmed zero rows in payments/orders — pre-launch data fix, not
a refund situation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

crates/db/migrations/20260817000000_fix_pricing_packages_paise.down.sql

@@ -0,0 +1,5 @@
+BEGIN;
+
+UPDATE pricing_packages SET price_inr = price_inr / 100 WHERE price_inr >= 100 AND price_inr < 1000000 AND price_inr != 25000;
+
+COMMIT;

crates/db/migrations/20260817000000_fix_pricing_packages_paise.up.sql

@@ -0,0 +1,19 @@
+-- pricing_packages.price_inr is treated as PAISE by every consumer (see
+-- apps/payments/src/main.rs's paise_to_rupee_string call, and the comment
+-- on that column at apps/payments/src/main.rs:196) but 58 of the 59 rows
+-- (all but the JOB_SEEKER "Starter Pack" seeded correctly at 25000 = ₹250
+-- in 20260721070000_seed_pricing_packages.up.sql) were inserted with plain
+-- rupee-looking values (499, 999, 1999, 4999, 9999, ...). PayU would divide
+-- by 100 and charge 1/100th of the intended price, e.g. a "₹999 Growth"
+-- package would actually charge ₹9.99.
+--
+-- Threshold price_inr < 10000 catches exactly the mis-seeded rows and
+-- leaves the correctly-seeded 25000 row untouched. Confirmed no purchases
+-- have gone through pricing_packages yet (this is pre-launch), so this is
+-- a data-fix, not a refund situation.
+
+BEGIN;
+
+UPDATE pricing_packages SET price_inr = price_inr * 100 WHERE price_inr < 10000;
+
+COMMIT;