feat(ppc): add PPC API contracts and finance CostMasterLookupService

[ilramdhan]

Description

Adds the API contracts for the new PPC (Production Planning & Control) service, which
replaces the Excel-based monthly production planning workflow across the SPG, TXT and TWT
areas, plus a read-only finance lookup service that PPC consumes instead of duplicating the
finance cost masters.

Two logical changes:

1. finance/v1/cost_master_lookup.proto — a read-only projection of the finance cost
   masters for service-to-service consumption by PPC (and its BFF pickers). RPCs cover
   product master (single, batch, list, resolve-by-ERP-code), the released product route,
   product grades and product parameters (list + batch value fetch). Every RPC is a query —
   no mutation surface is exposed — so the calls can be authenticated by the shared internal
   service secret instead of a user JWT. ResolveCostProductMasterByErpCode exists so PPC
   can link Oracle sales-order staging rows to finance products by ERP item/shade code.

2. ppc/v1/* — the PPC module, split by bounded context, with all RPCs aggregated
   behind a single PPCService exposed over gRPC and, via grpc-gateway annotations, REST
   under /api/v1/ppc/*.

Both are additive: no existing message, field number or RPC was changed or removed.

Change Type

• ✨ New service/message
• ➕ Add field/RPC/enum value
• 🔄 Modify validation
• 📝 Documentation update
• ⚠️ Deprecation
• 🔧 Config/script changes

Proto Files Changed

• common/v1/common.proto
• finance/v1/uom.proto
• Other: finance/v1/cost_master_lookup.proto, ppc/v1/* (11 files), buf.gen.yaml, buf.gen.ts.yaml

Changes Made

• Add finance/v1/cost_master_lookup.proto — CostMasterLookupService, read-only product
  master / released route / grades / parameters lookups for internal callers.
• Add ppc/v1/common.proto — shared enums (area, demand type/sub-type/source/status, plan
  and work-order status, shift, grade requirement, quantity source, threshold level/unit).
• Add ppc/v1/master.proto — machine group, machine, lot, product PPC config, machine
  capacity and parameters, overrun threshold, downtime reason, waste category.
• Add ppc/v1/customer.proto — PPC customer master.
• Add ppc/v1/demand.proto — demand intake, sales-order staging, product linking.
• Add ppc/v1/plan_item.proto — monthly plan items.
• Add ppc/v1/work_order.proto — work-order lifecycle (draft → approval → running → closed).
• Add ppc/v1/changeover.proto — machine changeover records.
• Add ppc/v1/packing.proto — packing and grade actuals.
• Add ppc/v1/daily_performance.proto — shift entries, machine/area shift logs, efficiency
  snapshots.
• Add ppc/v1/dashboard.proto — aggregated dashboard reads.
• Add ppc/v1/ppc_service.proto — the single aggregated PPCService with google.api.http
  mappings under /api/v1/ppc/*.
• Extend buf.gen.yaml and buf.gen.ts.yaml inputs with the ppc module so both Go and
  TypeScript stubs are produced.

Conventions followed: decimal quantities are transported as strings to avoid float
precision loss, and the platform BaseResponse / PaginationResponse envelope from
common/v1/common.proto is reused, not redefined.

Related Issues

Fixes #
Related to #

Breaking Change Check

• No - buf breaking passes
• Yes - Requires version bump

Breaking Change Evidence:

buf breaking --against '.git#branch=main'
# no output — all changes are additive (new files + new generate inputs only)

Lint Check

buf format -w
buf lint
# no output

Generated Code Preview (Optional)

Go stubs land in goapps-backend/gen/ppc/v1/ and goapps-backend/gen/finance/v1/;
TypeScript stubs in goapps-frontend/src/types/generated/{ppc,finance}/v1/. Both are
committed in their respective consumer PRs (see merge order).

---

Pre-merge Checklist

• I have read and followed RULES.md
• buf format -w applied
• buf lint passes
• buf breaking passes
• Comments document new messages/fields
• REST mappings follow conventions
• Validation rules complete (buf.validate on request fields)
• Field numbers are logical

Impact Assessment

• Backend code regeneration required
• Frontend code regeneration required
• OpenAPI spec regeneration required

Reviewer Notes

Please review in this order: ppc/v1/common.proto (the enum vocabulary everything else
depends on) → ppc/v1/master.proto → the transactional contexts → ppc_service.proto for
the REST surface.

Worth a second look: finance/v1/cost_master_lookup.proto is deliberately query-only,
because the backend PR relaxes auth for exactly these methods when a valid internal service
secret is present. If any RPC there gains a mutating counterpart later, that allowlist has to
be revisited.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.