[fix][star-rating] bind the widget rating counters to the submitting app (24.05)

[ar2rsawseen]

The widget rating counters were updated by widget id alone:

common.db.collection('feedback_widgets').update({
    _id: common.db.ObjectID(currEvent.segmentation.widget_id)
}, { $inc: { ratingsSum: currEvent.segmentation.ratingSum, ratingsCount: 1 } }, ...)

The widget id arrives in the submitted event's segmentation, so ingestion for one app could move ratingsSum and ratingsCount on a widget belonging to another. The feedback row itself was already written to the submitting app's own collection, so only the aggregate needed binding. It now carries app_id like every other selector against this collection (lines 565, 726, 817, 1117), matching the same params.app_id + "" string convention.

What this is and is not

It closes an app boundary rather than a capability. Anyone holding an app's public key can already submit ratings against that app's own widgets through this same path, which is what public ingestion is for, so those counters were always movable by whoever held the key. What was wrong is that a different app's key could move them, and that the resulting aggregate then had no feedback rows behind it in the affected app.

timesShown is deliberately unchanged

/o/feedback/widget takes no app key and has no app context, and the widget id it receives already determines the app, so adding app_id to that selector would compare a value against itself. An unauthenticated caller incrementing an impression counter on a public widget endpoint is what that endpoint is for. Changing it would mean requiring a key there and breaking SDK clients that do not send one.

Related: 6331a78 scoped the dashboard write routes (remove, edit, bulk-status) to the authorised app. This selector was outside that change's scope and is the same idea applied to the ingestion path.