Inconsistent inode numbers for mounted files

### Description

I'm trying to run fluent-bit inside of gVisor. It uses a `hostPath` mount to read all the container logs to then forward them somewhere else. In order to keep track of what was already dealt with, it writes a sqlite DB file to the disk (also a `hostPath` in my case). It keeps track of the underlying files by path **and inode**.

After noticing some log duplication after rolling my pods, I've dug in and it seems like the files mounted via the `hostPath` mount do not have consistent inode numbering. It varies from restart to restart of the container. That completely breaks any kinda tracking fluent-bit could be doing in this case.

The inode numbers are very low, suggesting to me that gvisor is doing some internal assignment of these numbers. The "real" inodes are way higher.

I've tried switching `directfs` and `overlay2` on and off but haven't noticed any change in behavior.

### Steps to reproduce

Run the following pod and compare the logs it produces. Preferably, there's a couple of pods on the same machine to trigger the effect.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
app-component: web
template:
metadata:
labels:
app-component: web
spec:
volumes:
- hostPath:
path: /var/log
type: ""
name: varlogs
containers:
- name: test
image: busybox
command: ["sh", "-c", "ls -li /var/log/containers"]
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /var/log/
name: varlogs
readOnly: true
restartPolicy: Always
```

### runsc version

```shell
runsc version release-20240212.0-28-g1303df5f706e
spec: 1.1.0-rc.1
```

### docker version (if using docker)

_No response_

### uname

Linux pool-apps-appworkload-shared-s-4vcpu-8gb-o6j7h 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux

### kubectl (if using Kubernetes)

_No response_

### repo state (if built from source)

_No response_

### runsc debug logs (if available)

_No response_