feat(backend-js): add a Node.js implementation of the Quickstart backend

[fernandomg]

Close digital-asset#156

Summary

• Adds a Node.js / TypeScript / Fastify backend that mirrors the Java backend's HTTP API surface, selectable at build time via BACKEND=js (persisted in .env.local by make setup).
• Both backends share the same OpenAPI contract, env files, onboarding volume, listening port, and cookie/CSRF auth surface (OAuth2 and shared-secret). The JS backend talks to Canton via the JSON Ledger API on port 3975 instead of gRPC, reads PQS Postgres directly, and uses the dpm codegen-js Daml bindings for typed command construction. The Compose stack swaps in the JS service via an override file when BACKEND=js.

Test plan

• Ran make clean-all && make setup and answered js to the new interactive Backend prompt — alongside the existing prompts for AUTH_MODE, OBSERVABILITY_ENABLED, TEST_MODE, and PARTY_HINT. The selection is written to .env.local as BACKEND=js, so every subsequent make start / make restart-backend / make stop automatically targets the JS service without needing to repeat the flag. Re-ran make setup and chose java to confirm the prompt round-trips and that the stack swaps back to the Java backend cleanly. Verified under both AUTH_MODE=oauth2 and AUTH_MODE=shared-secret.
• Walked through the entire flow described in the Explore the Demo guide (https://docs.digitalasset.com/build/3.5/quickstart/operate/explore-the-demo.html): App User and App Provider login, tenant pre-registration via register-app-user-tenant, AppInstallRequest accept/reject, License issuance, the renewal flow with wallet allocation, and license expiry. Each step produced behaviour identical to the Java backend.

Deferred to follow-up

The items below were surfaced during review and consciously left out of this PR. Each one is either parity-equal with the Java backend (so a JS-only fix would create drift) or a production-hardening concern that needs a cross-cutting design touching both backends. They should be tracked in a follow-up issue against both implementations.

#	Issue	Why deferred
1	SESSION_SECRET falls back to random bytes per restart in backend-js/src/auth/session.ts, invalidating signed session cookies.	Java's in-memory HttpSession produces the same observable behaviour: every restart logs all users out (signature mismatch in JS, lost server-side state in Java). Fix needs a stable signing secret and a persistent session store applied to both backends.
2	Raw Canton ledger error text is forwarded to HTTP clients (party IDs, template IDs, choice arguments).	Java's application.yml explicitly enables include-message: always, include-stacktrace: always, include-exception: true for dev — leaks at least as much, with stacktraces. A sanitising error mapper needs to land on both backends together.
3	Malformed duration strings throw → HTTP 500 where 400 would be the correct status.	Same behaviour in Java: Duration.parse throws DateTimeParseException and there is no @ControllerAdvice mapping it to 400. Fix on both sides in one PR.
4	DELETE /admin/tenant-registrations/:tenantId removes the OAuth2 registry entry before the tenant repo entry; if step 2 fails the registry is gone but the tenant remains.	Java's deleteTenantRegistration uses the same ordering and has the same risk window. Proper transactional/rollback handling needs to land on both backends.
5	The 201 response body for AppInstallRequest_Accept does not include the new AppInstall's contractId.	Same omission in Java's AppInstallRequestsApiImpl#acceptAppInstallRequest. The OpenAPI response shape and the choice-result extraction need to be updated together on both sides.