add: sessions key registry in DevnetInfo, remove post and seal layers from curio

[redpanda-f]

• synapse-sdk needed sessions key registry addr, which was not exported earlier
• post and seal layers can be disabled for PDP layer only operations

[Copilot]

Pull request overview

Adds the SessionKeyRegistry contract address to the exported DevnetInfo so external consumers (e.g. synapse-sdk) can discover it, and simplifies Curio startup by disabling seal/post layers for PDP-only workflows.

Changes:

• Export session_key_registry_addr in DevnetInfo/ContractsInfo and update the JS schema accordingly.
• Extend FOC deploy output parsing to capture the SessionKeyRegistry address from a pre-summary log line.
• Update Curio layer configuration to run only pdp-only,gui.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/external_api/export.rs	Adds session_key_registry_addr extraction from SetupContext into exported devnet-info JSON.
src/external_api/devnet_info.rs	Extends ContractsInfo schema with session_key_registry_addr.
src/commands/start/foc_deployer/mod.rs	Parses SessionKeyRegistry deployed at ... output and records it in the deployment addresses map.
src/commands/start/curio/constants.rs	Removes seal and post from the Curio --layers argument.
examples/devnet-schema.js	Updates Zod schema to require session_key_registry_addr in contracts.

[Copilot]

extract_address_from_deployed_line returns the entire substring after deployed at , so if the deploy script ever prints anything after the address (e.g. trailing commas, extra text, ANSI codes), the stored value will not be a valid 0x address and downstream consumers will break. Consider extracting only the first token, then validating it is exactly 42 chars (0x + 40) and hex before returning.

Suggested change

	fn extract_address_from_deployed_line(line: &str) -> Option<String> {
	let marker = "deployed at ";
	let idx = line.find(marker)?;
	let addr = line[idx + marker.len()..].trim();
	if addr.starts_with("0x") && addr.len() >= 42 {
	Some(addr.to_string())
	fn is_valid_hex_address(token: &str) -> bool {
	if token.len() != 42 {
	return false;
	}
	if !token.starts_with("0x") {
	return false;
	}
	token[2..].chars().all(|c| c.is_ascii_hexdigit())
	}
	fn extract_address_from_deployed_line(line: &str) -> Option<String> {
	let marker = "deployed at ";
	let idx = line.find(marker)?;
	let rest = line[idx + marker.len()..].trim();
	let first_token = rest.split_whitespace().next()?;
	if is_valid_hex_address(first_token) {
	Some(first_token.to_string())

[rvagg]

not a bad point, but also maybe irrelevant since we control the code; not a bad thing to be as robust as we can though

[Copilot]

The SessionKeyRegistry deployed at special-case always continues even when extract_address_from_deployed_line returns None. If the deploy output format varies slightly (e.g. deployed at: with a colon, extra prefixes), this will skip the line entirely and the address won't be captured. Consider only continue after successfully extracting an address, or falling back to the generic parsing path when extraction fails.

Suggested change

	}
	continue;
	continue;
	}

[rvagg]

good point

[BigLep]

This is being done in support of #7, and particularly FilOzone/synapse-sdk#600

[rvagg]

oh, good catch
also I thought it was pdp, I didn't know pdp-only was a thing, hopefully this simplifies the running instances a little

[rvagg]

approving but those two copilot items would be worth fixing, more resilience when dealing with parsed log output