The counters are primarily used as boolean to determine whether or not
to display the card. Therefore, as soon as you have one record, we can
show the card without needing to recheck it later. In the worst-case
scenario, you might see a card pointing to an empty list view.
This approach helps us avoid recalculating whether there is a record for
this card on each refresh.

The approach is to cache the counter in the session as soon as there are
more than 0 records. This way, if there are no invoices but a sale order
is validated, the invoice counter will be recomputed, and you will see
the invoice card the next time. For the duration of the same session, we
won't recompute it and will always display the invoice card.
We only re-request the computation if the counter in the session was 0
or if we need to show the counter, as in this case, we want to display
the most precise number.

This approach will also avoid flickering when the view is updated.
Since we already know the count, we can display the card immediately
without waiting for the RPC callback. To further reduce flickering, we
have moved the spinner to the bottom, preventing the content from
shifting upwards once the loader disappears.

On another note, we've updated the policy for the parallel RPC requests
made to /my/counter. Instead of splitting the counter into 3 RPC calls,
we now allow 5 counters per RPC, with a maximum of three RPCs.

An update of the view portal.portal_docs_entry is required to benefit
from this cache for /my/counter,