feat(dirctl): embed zot into daemon subcommand

[arpad-csepi]

This PR removes the local OCI implementation backed by ORAS and adds an optional embedded Zot registry to the dir daemon flow, configured under daemon.zot. When enabled, the daemon starts Zot as an daemon process and points the apiserver OCI store at that registry.

The changes also add unit test and README.md for documentation.

The k8s.io go packages required to be downgraded because zot go package has older version than latest.

These changes enables to provide sync operation and federation in local development environments which detailed here: #1353

Resolves: #1352

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / verify-proto (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	⏩ skipped	✅ passed	Apr 28, 2026, 12:23 PM

[ramizpolic]

i would reconsider the way we configure the zot/oci registry here. my suggestion is to do the following:

• Server storage config can either be a) local dir or b) remote registry
• For local-dir storage, do the following:
  • the folder is used as a backing store
  • ZOT in-proccess is started at a random port
  • there is no mention of zot

Example configs

Remote registry

store:
    provider: "oci"
    oci:
		# uses remote-OCI registry

Local registry

store:
	provider: "local"
	data_dir: "./dir/to/data" # where the data will be backed
	registry_address: "localhost:5000" # what the OCI storage endpoint will be (in-process ZOT)

[arpad-csepi]

As the in-process Zot is integrated to dirctl not the apiserver I think we should not pollute the server store config with options what are not used by the server itself (like data_dir). So how I see it is that the server config describe where to connect, daemon config is to where to serve.

With this daemon section approach (which only applies to the daemon config), the user can set up any daemon related option without using server config later as well if we want to expand.

Also might be better to restructure the daemon config to include the apiserver as a subsection, so we can include the server config as is.

Daemon config

apiserver:
  store:
    provider: "oci"
    ...

daemon:
  zot:
    ...

WDYT? Should we create a unique config for the daemon or still want to include all options to the server config?

[arpad-csepi]

If we add the option to the user to set where to serve the local zot then they can know all info how use it with apiserver and/or integrate with other stuff.
If we add the option to set where to listen and random pick a port then the user has no idea where to find the local zot and has the possibility for that port is already in-use.