Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/public-api/src/controllers/data.controller.js`:
- Around line 535-553: The code path inside the non-external DB block returns
raw JSON errors (res.status(404).json({ error: ... }) and res.status(403).json({
error: ... })) which breaks the controller contract; replace those returns with
the standard error handling using the AppError class and the controller's error
middleware (e.g., import AppError and call next(new AppError("Document not
found.", 404)) for the 404 and next(new AppError("Storage quota exceeded. Please
upgrade your plan.", 403)) for the quota check) so errors follow the { success,
data, message } response shape and no raw DB details are leaked; update
references in this block (the existingDoc check and the quota branch that uses
sizeDelta / project.databaseUsed/project.databaseLimit) accordingly.
- Around line 532-571: The current flow does findOne → local quota check →
findOneAndUpdate → separate Project.findByIdAndUpdate which allows race
conditions and never decrements storage for shrink updates; fix by performing
the document read, quota check, document update and Project.$inc inside a single
MongoDB transaction/session so the quota check and the $inc are atomic: use
mongoose.startSession(), session.startTransaction(), perform
Model.findOne({queryFilter}).session(session) to get existingDoc (abort if
null), compute sizeDelta = newSize - oldSize, if sizeDelta>0 verify
(project.databaseUsed || 0) + sizeDelta <= project.databaseLimit else allow
negative deltas, then run Model.findOneAndUpdate(queryFilter, { $set:
sanitizedData }, { new: true, runValidators: true, session }) and
Project.findByIdAndUpdate(project._id, { $inc: { databaseUsed: sizeDelta } }, {
session }), commitTransaction on success and abort/rollback and return
appropriate error on failure; ensure you always apply the computed sizeDelta
(can be negative) so shrinks free quota and avoid separate non-atomic updates
via Project.findByIdAndUpdate outside a transaction.
- Around line 288-299: The code clamps limit only in responseMeta but still uses
the raw parsed value when paginating; compute a single clampedLimit (e.g. const
limit = Math.max(1, Math.min(parseInt(req.query.limit, 10) || 100, 100))) before
any pagination logic and use that variable wherever slicing/pagination occurs
(cursor handling, nextCursor calculation, or array.slice calls) and also
reference the same limit variable in responseMeta; update any places using the
raw parsed value so nextCursor and returned metadata are consistent.
- Around line 200-206: In bulkInsertData (and the related bulk insert error
branches) the AppError constructor is being called with the arguments reversed;
AppError expects (statusCode, message). Update each call in data.controller.js
(notably the branches using isDuplicateKeyError and the final bulk insert
failure path) to call new AppError with the status code first and the error
message second (e.g., new AppError(409, "Duplicate value violates unique
constraint.") and new AppError(500, "Failed to insert bulk data")). Ensure all
occurrences in bulkInsertData use this corrected argument order.