Your assumptions are incorrect in my view...
Those exist, but you can't use them if the hub effectively doesn't exist on the network. Put another way, the Hub's primary functionality is via an IP network. tcp/80 specifically.
The Hub will attempt to get a dynamic IP address via DHCP. It will then attempt to use that IP to get to the Hubitat cloud server and 'check-in' (and get info such as is there an update, etc.) Not having a valid IP successfully defeats both. The transition from no led to blue to green is indicative of a successful boot of the platform OS. It believes it's gotten an IP... which can probably include:
" 169.254.x.x: This is what's called an Automatic Private IP address. An IP in this range means that the computer cannot see the network. A computer using DHCP needs to have an external server tell it what IP address to use. Unfortunately, if there's no network connectivity, the computer is unable to talk to the server. In those cases, the computer will actually give itself an IP starting with 169.254, since it must assign itself some sort of number. "
There is an autonegotiation issue that has been resolved BUT requires the aforementioned network connectivity. Specifically this is regarding the speed/duplex of the network connection... the hub get lots of errors and retries to overcome. It does overcome BUT the UI appears VERY slow. This is completely different from not having a valid IP. the hub will detect the autonegotiation problem, report it to the Hubitat Cloud and a fix will be sent to your hub in about 24 hrs. Obviously that requires a 'good enough' network connection.
All of my words above are directly a result of that "clue" you provided.
The hub does NOT require a static/reserved IP but we humans will like it better if it gets one. That way we know where it's supposed to be. Eventually you may add an app or an integration that will need a fixed address.. can't hurt to start now.
If you can, use the MAC address on the bottom of the Hub to make an IP address reservation in your router. Then unplug the NETWORK wire for 15 mins and when you plug it back in, it should try DHCP again. Watch the lights on your Router when you plug it in.. they should begin OFF and then do a bunch of blinking as it negotiates. While waiting the 15 mins, move some other cable from it's connection on the router and plug it into the socket the Hub has been using. Everything works? Not a bad router socket, right?
100/full into a 100/half will be full of errors BUT it should be able to get DHCP because it's functioning as half duplex in that exchange. The Hub says: "Hey" and switches to Listen. DHCP says "your address sir." they don't overlap.
Do you have some cranky old switch you retired? It might not run into the autonegotiation problem and allow the Hub to get to the point where it can self repair.