Modifying (`.add()`, `.subtract()`, etc.) a dayjs instance created in UTC corrupts it

Setting timezone explicitly
-
`dayjs.tz(0, 'UTC').format()`

`'1970-01-01T00:00:00Z'` - Result
`'1970-01-01T00:00:00Z'` - Expected
___

`dayjs.tz(0, 'UTC').add(0,'minutes').format()`

`'1969-12-31T23:00:00Z'` - Result
`'1970-01-01T00:00:00Z'` - Expected
___

`dayjs.tz(0, 'UTC').add(1,'minutes').format()`

`'1969-12-31T23:01:00Z'` - Result
`'1970-01-01T00:01:00Z'` - Expected

Setting default timezone
-

The above results are identical, when omitting `'UTC'` and setting UTC as default:

`dayjs.tz.setDefault('UTC')`

`dayjs.tz(0).format()`

`'1970-01-01T00:00:00Z'` - Result
`'1970-01-01T00:00:00Z'` - Expected
___

`dayjs.tz(0).add(0,'minutes').format()`

`'1969-12-31T23:00:00Z'` - Result
`'1970-01-01T00:00:00Z'` - Expected
___

`dayjs.tz(0).add(1,'minutes').format()`

`'1969-12-31T23:01:00Z'` - Result
`'1970-01-01T00:01:00Z'` - Expected
___

**Information**
- Day.js Version 1.11.5
- OS: Mac
- Browser: Chrome

Start by reproducing the reported dayjs.tz(...).format() and .add() examples, both with an explicit 'UTC' and after dayjs.tz.setDefault('UTC'). Then trace the timezone-related implementation and existing tests to identify why modification changes the displayed hour; done means the reported zero- and one-minute cases retain the expected UTC dates.

Written by the indexing model from the issue text.