# Title

Reconfiguring `import keep filtered` from off to on does not preserve already rejected routes

# Description

Changing a channel from `import keep filtered off` to `import keep filtered on` does not cause existing rejected routes to be reprocessed. Two histories with the same final static route, import filter, and `import keep filtered on` setting end with different filtered-route state.

When the route is present before `import keep filtered` is enabled, it has already been dropped and is not re-fed after reconfiguration. When BIRD starts directly with the final configuration, the same route is retained as filtered.

# Version

Reproduced with:

```text
BIRD 2.18+branch.master.f0f859c26cf9
```

# How to reproduce

1. Use a single BIRD instance. No external peers are required.

   ```text
                +-------------+
                |     r1      |
                |             |
                | BIRD static |
                +-------------+
   ```

2. Configure a static protocol route:

   ```bird
   protocol static static_reject {
       ipv4 {
           import filter {
               if net = 198.51.80.0/24 then reject;
               accept;
           };
           import keep filtered off;
       };

       route 198.51.80.0/24 unreachable;
   }
   ```

3. Start BIRD and confirm the rejected route is not retained as filtered:

   ```bash
   birdc show protocols all static_reject
   ```

4. Reconfigure only the channel option from `import keep filtered off` to `import keep filtered on`, keeping the same static route and same import filter.

5. Check the protocol counters again:

   ```bash
   birdc show protocols all static_reject
   birdc show route filtered protocol static_reject all
   ```

6. As a control, restart BIRD directly with the final configuration (`import keep filtered on`) and the same static route/filter, then compare the same outputs.

# Expected behavior

Because both histories end with the same route, the same import filter, and `import keep filtered on`, BIRD should retain the rejected route as filtered in both cases. The protocol route counters should report one filtered route.

# Actual behavior

History A reports no retained filtered route:

```text
Routes:         0 imported, 0 filtered, 0 exported, 0 preferred
```

History B reports the expected filtered route:

```text
Routes:         0 imported, 1 filtered, 0 exported, 0 preferred
```

# Additional context

`import keep filtered` changes how rejected routes are represented in channel state. The suspected path is `nest/proto.c:channel_reconfigure()`, which handles several channel changes but does not appear to trigger a reload/refeed for `in_keep_filtered` changes. `nest/rt-table.c:rte_update2()` decides whether rejected routes are dropped or retained as `REF_FILTERED` based on `c->in_keep_filtered`, so changing that flag without refeeding existing routes leaves history-dependent filtered state.