Feature Request: Change default save path of uploaded image in `fields.markdoc()` relative to entry

With this keystatic config

// in ./keystatic.config.ts

import { config, fields, collection } from '@keystatic/core';

export default config({
  storage: {
    kind: 'local',
  },
  collections: {
    post: collection({
      label: 'post',
      path: 'src/content/post/**/',
      schema: {
        //...
        content: fields.markdoc({
          label: 'Content',
          description: 'The content of the post',
        }),
      },
    }),
  },
});

Each new entry (post) is saved in
src/content/post/<POST_SLUG>/index.mdoc.
So far so good...

The content field has a Markdown editor UI where we can upload images, and these images will be saved to
src/content/post/<POST_SLUG>/content/<IMAGE.JPG>.

I need that instaed images can be saved in the root directory of the entry, not inside content subdiretory.
Like this
src/content/post/<POST_SLUG>/<IMAGE.JPG>.

What I tried

1. Adding options to fields.markdoc

content: fields.markdoc({
  label: 'Content',
  description: 'The content of the post',
  options: {
    image: {
     
     // This path is relative to root project, not entry directory
     // So it cannot do what i need
     directory: ".", 
      
      // This function receive only the filename of the image, not the save path.
      // i.e.
      // If image is saved in `content/<IMAGE.JPG>` this function `originalFilename` is `<IMAGE.JPG`>
      // So it cannot do what i need
      transformFilename(originalFilename) {
        return originalFilename;
      },
    }
  }
}),

What i'm requesting

Ability to define path where an image will be saved , relative to the entry directory.
Or it is already possible ?

Start in the keystatic.config.ts example and trace the fields.markdoc image options to where uploaded files are assigned their directory. Check how the entry path and content subdirectory are determined. Done means supporting an entry-relative image path that saves files in src/content/post/<POST_SLUG>/ rather than its content subdirectory, with coverage for the configuration.