Improve key management/isolation #631

Behavior regression: aggregator with admin-token only. aggregator.rs no longer sends the admin token when fetching /status; it relies on the default Authorization: Bearer <api_token> header set in Aggregator::init. But ServerConfig allows --admin-token without --api-token (the assertion at server.rs:235 only requires admin if api is set). An aggregator deployed with only an admin token will now get 401s from auth-enabled peers' /status and silently report blockheight: 0 (fetch errors are filtered out in blockheight). Previously this worked. Either send config.api_token().or(config.admin_token()) in Aggregator::init, or document that aggregators now require an api token. The updated tests (aggregator_blockheight_returns_minimum) only cover the both-tokens case, so this regression wouldn't be caught.

I don't know if you're gonna do this in a follow up but this seems relevant: Behavior regression: aggregator with admin-token only. aggregator.rs no longer sends the admin token when fetching /status; it relies on the default Authorization: Bearer <api_token> header set in Aggregator::init. But ServerConfig allows --admin-token without --api-token (the assertion at server.rs:235 only requires admin if api is set). An aggregator deployed with only an admin token will now get 401s from auth-enabled peers' /status and silently report blockheight: 0 (fetch errors are filtered out in blockheight). Previously this worked. Either send config.api_token().or(config.admin_token()) in Aggregator::init, or document that aggregators now require an api token. The updated tests (aggregator_blockheight_returns_minimum) only cover the both-tokens case, so this regression wouldn't be caught.

src/subcommand/server/node_tokens.rs

					
				@ -0,0 +26,4 @@

				        }

				        let admin = parts.extensions.get::<BearerAuth>().is_none_or(|auth| {

				            !auth.enabled()