Orders entity not used when calculating EoA renewal price

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

When a subscription is renewed based on EoA starter / bronze offer terms, the [description in the amendment record](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e88993e6fa567f72e1eb5207be0a87954f16cc5c/app/services/amendment_base_service.rb#L162) is set to `'EoA Bronze / Starter Price Uplift'`. With the transition to Orders API, this description was set in the charge overrides, accessible in Rate plan charge record (source: [`AddProduct`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e88993e6fa567f72e1eb5207be0a87954f16cc5c/app/services/zuora/orders/actions/param_constructor/add_product.rb#L73), [`UpdateProduct`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e88993e6fa567f72e1eb5207be0a87954f16cc5c/app/services/zuora/orders/actions/param_constructor/update_product.rb#L28) order actions)

However, while calculating the renewal price, we use the [count of amendments](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e88993e6fa567f72e1eb5207be0a87954f16cc5c/app/services/eoa_starter_bronze/offer_renewals_count_service.rb#L14) that have description set to `'EoA Bronze / Starter Price Uplift'`. It does not account for the charge overrides, which can result in a lower count and thereby returning the lower tier price.

This should likely not have an impact as of now, as we transitioned to Orders API for renewals on [January 19th](use_orders_api_subscription_update_workflow). For all EoA starter / bronze renewals following it, the count of description in amendment records represent the correct count. The charge overrides description will become relevant when the subscriptions are renewed the next time (i.e. the following year).

Spot checked a few subscriptions in production:

- [A-S00014461](https://www.zuora.com/apps/Subscription.do?method=view&id=8a12881086832d1e0186a19b26c312a2) (related renewal [Order](https://www.zuora.com/orders#/view/O-00100142))
- [A-S00008155](https://www.zuora.com/apps/Subscription.do?method=view&id=8a12827c86832d1d01869ed74c622ff7) (related renewal [Order](https://www.zuora.com/orders#/view/O-00103234)) 
- [A-S00038277](https://www.zuora.com/apps/Subscription.do?method=view&id=8a12827c86832d1d0186990541d41535) (related renewal [Order](https://www.zuora.com/orders#/view/O-00094065))

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

When calculating the next renewal price for EoA starter / bronze subscriptions, use Amendment description **and** charge overrides description. 

### Result

EoA step price is calculated accurately.

### Next steps (if any)

### How will we measure success?

Story points: 2.0