Skip bytes_permanent on re-renewal using existing TransactionKind

[mudigal]

#506

Summary

• Replace the AccountRenewals storage map and live-tracking machinery with a simple is_re_renewal: bool derived from the existing TransactionInfo.kind field. When the entry being renewed already has kind ==
• Renew, it was previously renewed — skip the bytes_permanent capacity check and increment to avoid double-counting across renewal cycles. This is essential for content kept alive permanently: without the skip, every RetentionPeriod re-renewal would exhaust the per-account quota even though no new distinct content was added.
• Make renew_content_hash feeless (consistent with renew which was already feeless)
• Fix enable_auto_renew snapshot check to use the renew-axis (bytes_permanent) instead of the store-axis (bytes/transactions)
• Refactor on_initialize obsolete-block cleanup to a single pass (avoids a redundant iteration and removes a .clone())

Test plan

• cargo test -p pallet-bulletin-transaction-storage — 92 tests pass
• cargo clippy --all-targets --all-features --workspace -- -D warnings — clean
• Verify re-renewal across multiple RetentionPeriod cycles on a local testnet

[bkontur]

I don't think we need this, we decrement/reset bytes_permanent when authorization window is expired and when creating new one for the same account:

polkadot-bulletin-chain/pallets/transaction-storage/src/lib.rs

Lines 1519 to 1525 in cb01db7

	if Self::expired(authorization.expiration) {
	// Expired-but-present: re-grant the caps, reset all consumed counters.
	// The new window's `bytes_permanent` quota is independent of any
	// renewed bytes still on chain from the old window.
	authorization.expiration = expiration;
	authorization.extent.bytes = 0;
	authorization.extent.bytes_permanent = 0;

We had "live per-account bytes_permanent tracking", but we decided to remove it and simplify stuff here: #486

[mudigal]

I don't think we need this, we decrement/reset bytes_permanent when authorization window is expired and when creating new one for the same account:

polkadot-bulletin-chain/pallets/transaction-storage/src/lib.rs

Lines 1519 to 1525 in cb01db7

	if Self::expired(authorization.expiration) {
	// Expired-but-present: re-grant the caps, reset all consumed counters.
	// The new window's `bytes_permanent` quota is independent of any
	// renewed bytes still on chain from the old window.
	authorization.expiration = expiration;
	authorization.extent.bytes = 0;
	authorization.extent.bytes_permanent = 0;

We had "live per-account bytes_permanent tracking", but we decided to remove it and simplify stuff here: #486

After an elaborate discussion about the slots. Due to the tight coupling between Poeple Chain slots and Bulletin Chain slots, the scenario doesnt even arise. As the problem is only within the Authorisation period. So reverted everything and updated the Authorisations design doc.

[rosarp]

all these are being worked on as TODO.
These are still needed to be done right @bkontur ?