Kubo does not reprovide pubsub routing CIDs (pubsubTopicRoutingCid, ipnsPubsubTopicRoutingCid) to delegated HTTP routers

### Checklist

- [x] This is a bug report, not a question. Ask questions on [discuss.ipfs.tech](https://discuss.ipfs.tech/c/help/13).
- [x] I have searched on the [issue tracker](https://github.com/ipfs/kubo/issues?q=is%3Aissue) for my bug.
- [x] I am running the latest [kubo version](https://dist.ipfs.tech/#kubo) or have an issue updating.

### Installation method

dist.ipfs.tech or ipfs-update

### Version

```Text
Kubo version: 0.39.0
Repo version: 18
System version: amd64/linux
Golang version: go1.25.4
```

### Config

```json
"API": {
"HTTPHeaders": {}
},
"Addresses": {
"API": "/ip4/127.0.0.1/tcp/0",
"Announce": [],
"AppendAnnounce": [],
"Gateway": "/ip4/127.0.0.1/tcp/0",
"NoAnnounce": [],
"Swarm": [
"/ip4/0.0.0.0/tcp/0"
]
},
"AutoConf": {},
"AutoNAT": {},
"AutoTLS": {},
"Bitswap": {},
"Bootstrap": [
"auto"
],
"DNS": {
"Resolvers": {
".": "auto"
}
},
"Datastore": {
"BlockKeyCacheSize": null,
"BloomFilterSize": 0,
"GCPeriod": "1h",
"HashOnRead": false,
"Spec": {
"mounts": [
{
"mountpoint": "/blocks",
"path": "blocks",
"prefix": "flatfs.datastore",
"shardFunc": "/repo/flatfs/shard/v1/next-to-last/2",
"sync": false,
"type": "flatfs"
},
{
"compression": "none",
"mountpoint": "/",
"path": "datastore",
"prefix": "leveldb.datastore",
"type": "levelds"
}
],
"type": "mount"
},
"StorageGCWatermark": 90,
"StorageMax": "10GB"
},
"Discovery": {
"MDNS": {
"Enabled": false
}
},
"Experimental": {
"FilestoreEnabled": false,
"Libp2pStreamMounting": false,
"OptimisticProvide": false,
"OptimisticProvideJobsPoolSize": 0,
"P2pHttpProxy": false,
"UrlstoreEnabled": false
},
"Gateway": {
"DeserializedResponses": null,
"DisableHTMLErrors": null,
"ExposeRoutingAPI": null,
"HTTPHeaders": {},
"NoDNSLink": false,
"NoFetch": false,
"PublicGateways": null,
"RootRedirect": ""
},
"HTTPRetrieval": {},
"Identity": {
"PeerID": "12D3KooWKBATFR1KJEVXQvAsWiJXHbw9rDLhGrdqzw3cBSUL5c6G"
},
"Import": {
"BatchMaxNodes": null,
"BatchMaxSize": null,
"CidVersion": null,
"FastProvideRoot": null,
"FastProvideWait": null,
"HashFunction": null,
"UnixFSChunker": null,
"UnixFSDirectoryMaxLinks": null,
"UnixFSFileMaxLinks": null,
"UnixFSHAMTDirectoryMaxFanout": null,
"UnixFSHAMTDirectorySizeThreshold": null,
"UnixFSRawLeaves": null
},
"Internal": {},
"Ipns": {
"DelegatedPublishers": [
"auto"
],
"RecordLifetime": "",
"RepublishPeriod": "",
"ResolveCacheSize": 128
},
"Migration": {},
"Mounts": {
"FuseAllowOther": false,
"IPFS": "/ipfs",
"IPNS": "/ipns",
"MFS": "/mfs"
},
"Peering": {
"Peers": null
},
"Pinning": {
"RemoteServices": {}
},
"Plugins": {
"Plugins": null
},
"Provide": {
"DHT": {
"Interval": "1m",
"SweepEnabled": false
},
"Strategy": "all"
},
"Provider": {},
"Pubsub": {
"DisableSigning": false,
"Router": ""
},
"Reprovider": {},
"Routing": {
"Methods": {
"find-peers": {
"RouterName": "HttpRouterNotSupported"
},
"find-providers": {
"RouterName": "HttpRoutersParallel"
},
"get-ipns": {
"RouterName": "HttpRouterNotSupported"
},
"provide": {
"RouterName": "HttpRoutersParallel"
},
"put-ipns": {
"RouterName": "HttpRouterNotSupported"
}
},
"Routers": {
"HttpRouter1": {
"Parameters": {
"Endpoint": "http://127.0.0.1:3000"
},
"Type": "http"
},
"HttpRouterNotSupported": {
"Parameters": {
"Endpoint": "http://kubohttprouternotsupported"
},
"Type": "http"
},
"HttpRoutersParallel": {
"Parameters": {
"Routers": [
{
"IgnoreErrors": true,
"RouterName": "HttpRouter1",
"Timeout": "10s"
}
]
},
"Type": "parallel"
}
},
"Type": "custom"
},
"Swarm": {
"AddrFilters": null,
"ConnMgr": {},
"DisableBandwidthMetrics": false,
"DisableNatPortMap": false,
"RelayClient": {},
"RelayService": {},
"ResourceMgr": {},
"Transports": {
"Multiplexers": {},
"Network": {},
"Security": {}
}
},
"Version": {}
}
```

### Description

I noticed a bug where IPNS-Over-Pubsub and pubsub routing CIDs are initially
provided to delegated HTTP routers, but are not reprovided after the configured
interval.

What I was doing:

- Started Kubo with delegated HTTP routing for `provide` and `find-providers`.
- Subscribed to a new pubsub topic and published a message.
- Generated a new IPNS key and published an IPNS record.
- Derived two routing CIDs:
- `pubsubTopicRoutingCid` from the new pubsub topic.
- `ipnsPubsubTopicRoutingCid` from the IPNS pubsub topic.
- Watched the HTTP router logs for `PUT /routing/v1/providers/`.

How the routing CIDs are calculated:

- `pubsubTopicRoutingCid`:
- Routing key is `floodsub:` using UTF-8 bytes.
- Hash is SHA-256.
- CID is CIDv1 with codec `0x55` (raw) and the SHA-256 multihash.
- Equivalent: `CID.createV1(0x55, sha256("floodsub:" + topic))`

- `ipnsPubsubTopicRoutingCid`:
- IPNS pubsub topic is `/record/` + base64url(`/ipns/` + PeerIdBytes(ipnsName)).
- Routing key is `floodsub:` using UTF-8 bytes.
- Hash is SHA-256.
- CID is CIDv1 with codec `0x55` (raw) and the SHA-256 multihash.
- Equivalent: `CID.createV1(0x55, sha256("floodsub:" + ipnsPubsubTopic))`

What I observed:

- Initial provide succeeded for both routing CIDs.
- After one reprovide interval, neither routing CID was reprovided to the HTTP router.

Steps to reliably reproduce:

1) Clone the repro repo and install dependencies.
```
git clone https://github.com/Rinse12/reproduce_kubo_bug_with_not_reproviding_ipns_pubsub_topic_routing_cid
cd reproduce_kubo_bug_with_not_reproviding_ipns_pubsub_topic_routing_cid/
npm install
node repro.js
```

2) The script will:
- Start a local HTTP router and Kubo daemon.
- Subscribe to a new pubsub topic, publish a message.
- Create and publish an IPNS record.
- Derive `pubsubTopicRoutingCid` and `ipnsPubsubTopicRoutingCid`.
- Check initial provide and then reprovide after the configured interval.

Expected behavior:

- Both routing CIDs are provided initially and reprovided every interval.

Actual behavior:

- Initial provides are seen.
- Reprovides are missing for routing CIDs.

Run the linked reproduction repo's repro.js and inspect the reprovide path for delegated HTTP routing, focusing on PUT /routing/v1/providers/ and the configured reprovide interval. Done means both pubsubTopicRoutingCid and ipnsPubsubTopicRoutingCid appear in the initial provide and in every subsequent reprovide.

Written by the indexing model from the issue text.