Why does an index scan read more pages than exist in an index?
You should check what code is submitted to the server when you open "Fragmentation" (using SQL Server Profiler)

And you'll see the following code:

select partition_number as PartitionNumber,
       index_type_desc  as IndexType,
       index_depth as Depth,
       avg_fragmentation_in_percent as AverageFragmentation,
       page_count   as Pages,
       avg_page_space_used_in_percent   as AveragePageDensity,
       record_count as Rows,
       ghost_record_count   as GhostRows,
       version_ghost_record_count   as VersionGhostRows,
       min_record_size_in_bytes as MinimumRecordSize,
       max_record_size_in_bytes as MaximumRecordSize,
       avg_record_size_in_bytes as AverageRecordSize,
       forwarded_record_count as ForwardedRecords 
from sys.dm_db_index_physical_stats(7, 773577794, 2, NULL, 'SAMPLED')


Note the mode: it's 'SAMPLED'.

The code returns only 1 row that reflects page_count of the leaf level of the index.

Now change the code to use 'DETAILED' and you'll find missing pages from non-leaf levels.

Here is my repro.

I first look at Fragmentation tab where I find that my ix_include_filler index has 20836 pages.

Then I executed the code that I saw in Profiler, and the code as it is uses "SAMPLED", returns 1 row and shows 20836 pages that we see in "Fragmentation" tab.

Then I changed "SAMPLED" to "DETAILED" and clearly see that these 20836 are only from a leaf level. Level N1 has other 36 pages + a root.

If your SSMS launches different code when you open Fragmentation tab, maybe you should update your question with SSMS version and spy the code it sends by yourself.

My SSMS's version is 10.50.6000.34 and my explanation is valid for this version.