why it is doing index seek
The purpose of the entire activity was to prove(as I am about to give
  presentation on statistics) that SQL Server looks into statistics to
  identify the number of records which matches the filter criteria of
  query before preparing the execution plan and based on the % of
  records matches out of total records in table, it will either decide
  to do a SCAN or SEEK. If % of records matches is approximately equal
  to total number of records in table, it should do SCAN.


this is incorrect so explains why you aren't seeing it. The BETWEEN 43659 AND 73659 range seek is doing a partial scan. It is just able to use the B-tree to seek into the point where to begin the scan (so avoid reading anything lower than 43659 ) and potentially exit early if there are rows with values greater than 73659. 

For the rows that are in the range it just reads the pages and follows the linked list to the next leaf page in exactly the same way as an index ordered scan does.

There is no reason to want a scan here. At best it saves a handful of logical reads for navigating from the root to the leaf to find the start point but at the expense of reading additional rows outside the range seeked.