ampl supply and utilization are broken

Ampl data on the graph is broken which is affecting rate-history and other services that might rely on thegraph data.

https://governance.aave.com/t/arc-fix-ui-bugs-in-reserve-overview-for-ampl/5885/5

// https://etherscan.io/address/0x6fBC3BE5ee5273598d1491D41bB45F6d05a7541A#code
  @title Aave-AMPL ERC20 AToken
  @dev Implementation of the interest bearing AMPL token for the Aave protocol
  @author AmpleforthOrg

  The AMPL AToken externally behaves similar to every other aTOKEN. It always maintains a 1:1 peg with
  the underlying AMPL. The following should always be true.

  1) At any time, user can deposit x AMPLs to mint x aAMPLs.
     Total aAMPL supply increases by exactly x.
  2) At any time, user can burn x aAMPLs for x AMPLs.
     Total aAMPL supply decreases by exactly x.
  3) At any time, userA can transfer x aAMPLs to userB.
     userA's aAMPL balance reduces by X.
     userB's aAMPL balance increases by X.
     Total aAMPL supply exactly remains same.
  4) When AMPL's supply rebases, only the 'unborrowed' aAMPL should rebase.
      * Say there are 1000 aAMPL, and 200 AMPL is lent out. AMPL expands by 10%.
        Thew new aAMPL supply should be 1080 aAMPL.
      * Say there are 1000 aAMPL, and 200 AMPL is lent out. AMPL contracts by 10%.
        Thew new aAMPL supply should be 920 aAMPL.
  5) When AMPL's supply rebases, only the part of the balance of a user proportional to  the available liquidity ('unborrowed') should rebase.
      * Say a user has deposited 1000 AMPL and receives 1000 aAMPL, and
        20% of the total underlying AMPL is lent out. AMPL expands by 10%.
        The new aAMPL user balance should be 1080 aAMPL.
      * Say a user has deposited 1000 AMPL and receives 1000 aAMPL, and
        20% of the total underlying AMPL is lent out. AMPL contracts by 10%.
        The new aAMPL supply should be 920 aAMPL.
  6) The totalSupply of aAMPL should always be equal to (total AMPL held in the system) + (total principal borrowed denominated in AMPL) + (interest)

aAMPL tokens are effected by rebase, but thegraph doesn't account for that.

4. should be solvable by listening to rebase events
5. i have no idea. fear this might not be solvable at all on thegraph as one would need to iterate trough userReserves on the rebase which is not possible 🤔

Start by tracing how the subgraph represents AMPL supply and utilization, then review the referenced rebase events and the stated aAMPL invariants. Done means the graph reports correct values for rate-history and dependent services, including a determined approach for user-level rebasing.