feat: implement dynamic config for manager

[frrist]

Summary

Introduce a dynamic configuration system that allows operators to tune the aggregation manager's behavior at runtime without restarting piri. This enables gas usage optimization by adjusting how frequently the manager polls for work and how many roots it batches together when adding to the chain.

Motivation

The aggregation manager is responsible for batching aggregated roots and submitting them on-chain. The cost of these operations depends on:

• Poll interval: How frequently the manager checks for pending work
• Batch size: How many roots are aggregated into a single on-chain submission

Previously, changing these values required editing the config file and restarting piri. This PR enables operators to:

1. Adjust configuration at runtime via CLI or HTTP API
2. Optionally persist changes to the config file
3. Reload configuration from file without restart

Changes

Core Dynamic Config Infrastructure (pkg/config/dynamic/)

Key design decisions:

• Schemas handle both parsing (string → typed) and validation in one step
• Updates are atomic: validate all values before applying any
• Persist failures trigger automatic rollback of in-memory changes
• Observer notifications happen outside the lock to prevent deadlocks

Manager Integration (pkg/pdp/aggregation/manager/)

Dynamic behavior:

• PollInterval: When changed, the manager's ticker immediately resets to the new interval
• BatchSize: Read on each poll cycle, no subscription needed

HTTP API (pkg/admin/httpapi/)

Endpoint	Method	Description
/admin/config	GET	List all dynamic config values
/admin/config	PATCH	Update config values (with optional persist)
/admin/config/reload	POST	Reload config from file

CLI Commands (cmd/cli/client/admin/config/)

# List all dynamic config values
piri client admin config list

# Get a specific value
piri client admin config get pdp.aggregation.manager.poll_interval

# Set a value (in-memory only)
piri client admin config set pdp.aggregation.manager.poll_interval 5m

# Set and persist to config file
piri client admin config set pdp.aggregation.manager.poll_interval 5m --persist

# Reload config from file
piri client admin config reload

Config Keys

Key	Type	Range	Default
pdp.aggregation.manager.poll_interval	Duration	1s - 1 year	30s (unchanged)
pdp.aggregation.manager.batch_size	Uint	1 - 500	10 (unchanged)

Example Usage

Scenario: Operator wants to reduce gas costs by batching more roots together and polling less frequently.

# Check current values
$ piri client admin config list
{
  "pdp.aggregation.manager.batch_size": 100,
  "pdp.aggregation.manager.poll_interval": "30s"
}

# Increase batch size and poll interval, persist to survive restart
$ piri client admin config set pdp.aggregation.manager.batch_size 200 --persist
$ piri client admin config set pdp.aggregation.manager.poll_interval 2m --persist

# Changes take effect immediately - no restart needed

[alanshaw]

Values that were set via the API but not persisted will remain unchanged.

How does that work? Do they not get replaced by the contents of the config file?

[frrist]

A Piri node starts with this config file:

[pdp.aggregation.manager]
poll_interval = "30s"

The node uses a poll interval of 30 seconds.

Runtime override (ephemeral):

piri client admin config set pdp.aggregation.manager.poll_interval 5m

The node now uses 5 minutes. The config file is unchanged.

Reload from file:

piri client admin config reload

The node returns to 30 seconds. The file wins; runtime overrides do not survive a reload.

Edit the file, then reload:

[pdp.aggregation.manager]
poll_interval = "5m"

piri client admin config reload

The node uses 5 minutes. The file still wins—it just agrees with you now.

Runtime override with --persist:

piri client admin config set pdp.aggregation.manager.poll_interval 10m --persist

The node uses 10 minutes and the config file is updated to match. Future reloads will preserve the change.

In summary, the config file is the source of truth. Runtime changes are ephemeral by default, they override behavior without touching the file. A reload restores the file's authority. The --persist flag exists for operators who mean it: change the behavior and update the file so the two agree. This prevents the most common configuration surprise: a system whose running state has silently diverged from its config file, discovered during a restart nobody planned for.