After conversation on irc it appears there's some cases where Bitcoin core will serve feerate information even though it loaded a fairly old fee estimates file and is still syncing the chain. This is pretty dangerous for lightning nodes, at least on legacy channels or pre-package-relay.

The immediate improvement would be to store fee estimates to disk once an hour or so to reduce the chance of having an old file. From there this case could probably be detected and refuse to serve estimates until we sync.
static const unsigned int OLDEST_ESTIMATE_HISTORY = 6 * 1008;
    
    static constexpr double SHORT_DECAY = .962;
    
    static constexpr double MED_DECAY = .9952;
    
    static constexpr double LONG_DECAY = .99931;
    
    static constexpr double HALF_SUCCESS_PCT = .6;
    
    static constexpr double SUCCESS_PCT = .85;
    
    static constexpr double DOUBLE_SUCCESS_PCT = .95;
    
    static constexpr double SUFFICIENT_FEETXS = 0.1;
    
    static constexpr double SUFFICIENT_TXS_SHORT = 0.5;
    /** Minimum and Maximum values for tracking feerates
     * The MIN_BUCKET_FEERATE should just be set to the lowest reasonable feerate we
     * might ever want to track.  Historically this has been 1000 since it was
     * inheriting DEFAULT_MIN_RELAY_TX_FEE and changing it is disruptive as it
     * invalidates old estimates files. So leave it at 1000 unless it becomes
     * necessary to lower it, and then lower it substantially.
     */
    static constexpr double MIN_BUCKET_FEERATE = 1000;
    static constexpr double MAX_BUCKET_FEERATE = 1e7;
    /** Spacing of FeeRate buckets
     * We have to lump transactions into buckets based on feerate, but we want to be able
     * to give accurate estimates over a large range of potential feerates
     * Therefore it makes sense to exponentially space the buckets