Primary Key At the End of Foreign Key index in MySQL is in order for sure?
FK is a constraint.  To facilitate checking that constraint, an INDEX is created.  Run SHOW CREATE TABLE for confirmation.  An InnoDB INDEX is expanded to include PK column(s).  Also, if there is an index with the leftmost column(s) matching the FK's column(s), the FK is happy.

When doing a SELECT, the Optimizer has many possible ways to do the query.  If you do not have an ORDER BY, then you must not assume the output is in any particular order.  The Optimizer may not have chosen the index you expect, or there could be a GROUP BY that is performed by first sorting, or the GROUP BY is done by hashing, hence randomly ordered.  Etc.

"Filesort" is a misnomer in two ways.  It may not involve a "file"; that is it might be done in RAM.  And it may need to be plural -- For example, GROUP BY a ORDER BY b is likely to involve two sorts.  EXPLAIN FORMAT=JSON ... is clearer on this than a plain EXPLAIN.

So, yes, the index for the FK is effectively as you describe (2 columns, ordered).  But so what?  Don't trust it; tack on an ORDER BY if you need the ordering.  As I mentioned above, the Optimizer is free to ignore that index.

A tip:  If you want to make use of both columns of the 'index' in question, then explicitly specify INDEX(base_id, record_id).  The FK should see that and say "That index is all I need; I won't make another one".  Humans reading your code will say "Hmmmm, the schema designer needs these two columns indexed for some reason".