Directly Cached Files: no way to remove an entry, and none at all once ABSPATH is read-only

## Summary

There is no control to remove an entry from the "Directly Cached Files" list. The "Delete cached file" button deletes the generated `index.html` (`inc/settings-forms.php:109-120`) and leaves the entry in `$cached_direct_pages`, so the row comes back on the next page load.

The only way to remove an entry is to blank its text input and submit, because `wpsc_update_direct_pages()` skips empty values:

```php
// inc/settings-forms.php:59
if ( $page != '' ) {
$cached_direct_pages[] = $page;
...
}
```

Nothing in the UI indicates that. The server side already supports removal — the handler rebuilds the whole list from `$_POST['direct_pages']` and computes `$expiredfiles` with `array_diff()` — so omitting an entry works. The form simply never offers a way to do it deliberately.

## The part that makes it a real gap

`partials/lockdown.php:32-34` marks the inputs `READONLY` when `ABSPATH` is not writable:

```php
$readonly = '';
if ( ! is_writeable_ACLSafe( ABSPATH ) ) {
$readonly = 'READONLY';
```

That is the configuration the plugin itself recommends. Its own warning on that screen reads:

> `%s` is writable. Please make it readonly after your page is generated as this is a security risk.

So a user who follows the plugin's advice can no longer edit the text inputs — and the blank-the-field workaround, already undiscoverable, becomes impossible. At that point there is no way at all to remove a direct page through the UI; it has to be done by hand in `wp-content/wp-cache-config.php`.

## Steps

1. Advanced tab → "Directly Cached Files" → add `/about/`.
2. Try to remove it. "Delete cached file" removes the HTML but the row persists.
3. Make `ABSPATH` read-only as the on-screen warning advises.
4. The inputs are now `READONLY`, so the entry cannot be removed at all.

## Suggested fix

A per-row remove control — a checkbox, or a second submit alongside `deletepage` — handled next to the existing `deletepage` branch in `inc/settings-forms.php`. It should stay available when `$readonly` is set, since removing a config entry does not require `ABSPATH` to be writable; only generating and deleting the static file does.

Worth deciding as part of this: whether removing an entry should also delete the generated file, or leave that to the existing button.

Suggested labels: `bug`, `ready-for-agent`.

Start with inc/settings-forms.php:59 and the existing deletepage handling around lines 109-120, then inspect partials/lockdown.php:32-34 for the readonly behavior. Add a deliberate per-row removal path that remains available when ABSPATH is readonly, and verify that the Directly Cached Files list can be updated without relying on blanking an input; decide whether generated files are removed separately or left to the existing control.

Written by the indexing model from the issue text.