Update DEPRECATION_HEIGHT to 5 333 777 to extend node support window

[DeckerSU]

We’ve extended the deprecation height to 5 333 777—about 619 days (1.5 years) ahead—so every node has plenty of time to upgrade before the auto-shutdown kicks in. At roughly 500 000 blocks per year (≈1 400 blocks/day), this change gives about 18 months of lead time for exchanges, services, and end users to deploy the new release without interruption.

[TheComputerGenie]

Shouldn't the logical deprecation height be based on an assumption/anticipation date of the next hard fork plus a buffer?
18 months seems needlessly excessive unless the plan is to change seasons on 18 month schedule rather than yearly, as it would create times where there's no meaningful change other than changing a variable shortly after having updated for seasons change.

Example:
deprecation height updated 18 months in advance
hf happens at month 15
month 18, 3 months after hf update, user must "update" a soft fork that may be no change other than deprecation height variable

[ca333]

Shouldn't the logical deprecation height be based on an assumption/anticipation date of the next hard fork plus a buffer? 18 months seems needlessly excessive unless the plan is to change seasons on 18 month schedule rather than yearly, as it would create times where there's no meaningful change other than changing a variable shortly after having updated for seasons change.

Example: deprecation height updated 18 months in advance hf happens at month 15 month 18, 3 months after hf update, user must "update" a soft fork that may be no change other than deprecation height variable

we plan to transition to KMD 2.0 (new protocol basis, PoS, etc.) by then thus added a bit of a buffer to not have to roll out another "depr height update" in the mean-time.