IP address missing from router DCHP table

Your Raspberry Pi uses a program called dhcpcd to obtain its IP address. It's a very good program, used now by most Linux distributions. dhcpcd is controlled/configured by the file /etc/dhcpcd.conf. You should have a look at man dhcpcd and man dhcpcd.conf when you have a few. But without being pedantic, this is what you should do to avoid the situation described in your question, and other issues:

from man dhcpcd.conf, see inform [address[/cidr[/broadcast_address]]]

Edit the file /etc/dhcpcd.conf to add the following line:

inform 192.168.1.16   # you can also add the CIDR and broadcast address if you like, but they are optional

If you're interested in "why", please read this answer

Don't be tempted to use the static_ipaddress option in /etc/dhcpcd.conf; man dhcpcd.conf is specific about this:

For IPv4, you should use the inform ipaddress option instead of setting a static address.

Summary:

If you use the inform ipaddress option in /etc/dhcpcd.conf, you will effectively have a static IP address, and you will see it in your router's DHCP table of leases.

I still fail to understand why Pi users want to set Static IP addresses.
If you really NEED a consistent address it is far better to reserve one on your router. (This also avoids the common errors.)

If you REALLY want to set a Static IP addresses AND have your router aware of it you can use the request or inform directive.

Extract from the dhcpcd man page:-

request [address]
Request the address in the DHCP DISCOVER message. There is no guarantee this is the address the DHCP server will actually give. If no address is given then the first address currently assigned to the interface is used.

inform [address[/cidr[/broadcast_address]]]
Behaves like request as above, but sends a DHCP INFORM instead of DISCOVER/REQUEST. This does not get a lease as such, just notifies the DHCP server of the address in use. You should also include the optional cidr network number in case the address is not already configured on the interface. dhcpcd remains running and pretends it has an infinite lease. dhcpcd will not de-configure the interface when it exits. If dhcpcd fails to contact a DHCP server then it returns a failure instead of falling back on IPv4LL.

I think you have probably already set the IP manually on the RPi, then are looking at a list of addresses that have been assigned by the router's DHCP server. If you set a static IP on the RPi, it doesn't use the router's DHCP server. Depending on router model, you may find another list of 'IP addresses on local network that have been used recently' and that would include the one that your RPi has assigned to itself. (On my router, I can see such addresses for ethernet wired connections, but not for WiFi connections).

If you instead tell your router's DHCP server to 'always give the following address to my RPi' (also known as "reserve" the IP address) you will see it on the list. That is probably a better way to assign a static IP address.

To answer your question:

Any idea why it might not be showing up?

A static ip address is a static ip address is a static ip address. It is not manged by any DHCP server, so you will not find a static ip address in its lease cache. That's by definition. You have to do everything by hand, define DNS server and gateway and other things you normally get from the DHCP server and you have to take attention that it does not conflict with the same ip address given by the DHCP server to another device. That's also the reason not to use static ip addresses for simple clients.

Sometimes I read a question and consider what a person is trying to do and why... and consider if there might be another way to solve the problem. This is one of those ... so this isn't a direct answer to your specific question, but possibly another strategy that will meet your needs.

I don't know that anyone will be able to tell you why your DHCP server (which sounds like it's on your router) isn't listing your Raspberry Pi's IP address lease. And that's not really a Raspberry Pi question ... it's more of a question about your DHCP server (which is probably really a question about your router).

But there might be another strategy that will fit your needs.

Multicast DNS

Both your Raspberry Pi and your Mac support mDNS. This is a protocol that's just built-in (you don't have to do anything) and it's a zero-configuration protocol (there are no files to maintain, nothing to turn on, etc. it "just works" as long as your OS has the feature). It let's computers on a network resolve other computers on that same subnet as if you were running an DNS server ... but without actually have to use a DNS server.

The implication here is that you don't need to worry about an IP address changing because the hostname will always work to resolve the host -- even if the IP address does change.

You need to know the hostname of the Pi (but only it's name). e.g. I have a Pi named "tims-raspi-8gb". mDNS will be used as long as you use the ".local" suffix when referring to the machine by name. e.g.:

tim@timsimac:~$ ping tims-raspi-8gb
ping: cannot resolve tims-raspi-8gb: Unknown host

tim@timsimac:~$ ping tims-raspi-8gb.local
PING tims-raspi-8gb.local (192.168.1.36): 56 data bytes
64 bytes from 192.168.1.36: icmp_seq=0 ttl=64 time=0.761 ms
64 bytes from 192.168.1.36: icmp_seq=1 ttl=64 time=0.389 ms

Notice in the first case when I omit the ".local" it gives me a "Unknown host" result. But in the second attempt when I do use the ".local" domain it resolves the host and "just works" even though I didn't actually know the IP address nor was this listed in my /etc/hosts file, etc.

mDNS uses multi-cast (as the name implies). Any host on the network that supports the protocol (which is most operating systems these days) is listening for the requests.

The client sends out a multi-cast request to everyone who is listening (all hosts running mDNS are listening) and basically asks who has that hostname. All the hosts hear the question, but all the hosts who aren't the host you want ignore it. The host that is the host you want will respond back with the info -- and now the IP address is resolved.

This works in any field that would accept a hostname or IP address. You can use it on the command line. You can use it in a web browser. You can use it when configuring software, etc. etc. It "just works".

There is one main caveat... this multi-cast request will NOT be copied over subnet boundaries. In order for this to work, all the hosts have to be on the same network subnet. If you have a home or office network that is divided into multiple subnets, this wont work across subnet boundaries. Also if you set up a VPN to remotely access your network, the VPN clients are generally treated as if they are on a different subnet ... so it wont work there either.

If you use Windows this gets a bit more nuanced... there is Windows support for mDNS but it isn't necessarily on by default. Windows users may have to test it and there is documentation on how to enable it -- but that's off-topic so I wont go into those details.