Handle Governor Limits

// A bulk update: 200 Opportunities all moving to Closed Won at once
List<Opportunity> opportunities = [SELECT Id FROM Opportunity WHERE StageName != 'Closed Won' LIMIT 200];
for (Opportunity opp : opportunities) {
    opp.StageName = 'Closed Won';
}
update opportunities; // fires OpportunityTrigger with all 200 records at once

Tracing through afterUpdate for this batch: the for loop over 200 records runs zero SOQL and zero DML — it only builds amountAdjustmentByAccountId in memory (Module 25's "collect" half). applyAdjustments then runs exactly one query and one update, regardless of whether those 200 Opportunities point to 200 different Accounts or all share the same one.

Scanning beforeUpdate and afterUpdate for anything that could scale with record count: the for loops themselves are pure in-memory work (no SOQL/DML inside them), addError() doesn't count as DML, and both applyAdjustments's query and update run exactly once regardless of batch size. This handler is bulk-safe as written — genuinely satisfying Module 25's core requirement, not just appearing to.

// applyAdjustments updates Account — if an AccountTrigger existed
// that itself updated related Opportunities, this could chain back
// into OpportunityTrigger again.

applyAdjustments's update accounts is itself a DML statement that could, in a more complex org with an AccountTrigger of its own, trigger a chain of further automation — this is exactly Module 24's trigger recursion concern, worth being aware of even though this specific module's simple version doesn't need a recursion guard yet.