Cardinality estimate outside the histogram
Based on my testing, the out-of-bounds cardinality estimate is simply the square root of the row count, bounded below by the number of added rows since the last stats update, and bounded above by the average rows per value.

In your case, 1,934.99 = SQRT(3744192)

Testing setup below:

--setup
USE TestDB
ALTER DATABASE [TestDB] SET AUTO_UPDATE_STATISTICS OFF
GO

DROP TABLE IF EXISTS dbo.Hist

CREATE TABLE dbo.Hist (
ID int identity primary key,
Num int
)

INSERT dbo.Hist
SELECT TOP 300
(ROW_NUMBER() OVER(ORDER BY(SELECT 1/0)))%3
FROM master..spt_values a
CROSS JOIN master..spt_values b


--Get estimated plan
--don't forget to run right after setup to auto-create stats
SELECT *
FROM dbo.Hist
WHERE Num = 1000


--gradually add rows, then rerun estimate above
INSERT dbo.Hist
SELECT TOP 100
-1
FROM master..spt_values a


--I sure hope you weren't testing this in prod (cleanup)
ALTER DATABASE [TestDB] SET AUTO_UPDATE_STATISTICS ON
GO


Surprisingly even row estimates were generated from this approach:
20 at 400 total rows,
30 at 900,
40 at 1600, etc.

Past 10000 though, the row estimate maxes out at 100, which is the number of rows per value in the existing stats. Adding only 10 rows will set the estimate to 10, since sqrt(300) > 10.

Thus the estimates could be expressed using this formula:

Estimate = MIN(SQRT(AC), MIN(AR, MC))


Note that if statistics are sampled, then MC is not considered. So the formula becomes:

Estimate = MIN(SQRT(AC), AR))


Where 


MC is the "modification count" (# of modifications since the statistics were created)
AC is the "adjusted cardinality" (# of rows from the statistics plus MC), 
AR is the average rows per value (# of rows from the statistics divided by distinct values in the column)


The formulas for these estimates, and other details about the calculator, can be found in this blog post: Analyzing Estimates from the CSelCalcAscendingKeyFilter Calculator