basics/pda-rent-payer: create_new_account has no caller check — worth a note for people copying it?

create_new_account spends from a program-owned vault, and nothing in the
instruction constrains who may call it.

The accounts struct is:

pub struct CreateNewAccount<'info> {
    #[account(mut)]
    new_account: Signer<'info>,

    #[account(mut, seeds = [b"rent_vault"], bump)]
    rent_vault: SystemAccount<'info>,
    system_program: Program<'info, System>,
}

new_account is a Signer, but it signs for itself — it is the account being
created, and the caller generates that keypair. rent_vault is a PDA on a
single literal seed, shared by everyone. So there is no authority account and
no has_one, and each call moves one rent-exempt minimum out of the shared
vault into an account the caller controls.

That is almost certainly intentional for the example's purpose — it exists to
show a PDA signing for itself, and it does that cleanly and readably. My
question is only about the people who copy it, since a rent vault is exactly
the kind of helper that gets lifted into a real program.

Would a short comment on the accounts struct be welcome? Something like:

// NOTE: this example does not restrict who may call it. A real rent vault
// needs an authority check — a `has_one` against an admin recorded at
// initialisation, seeds that bind the vault to one funder, or a per-caller
// limit. (A bare `authority: Signer` alone is not enough — any keypair
// can sign for itself.)

Happy to open a PR with just that comment if it's useful. I did not want to add
a constraint, since that would change what the example teaches.

For context: basics/checking-accounts is the example that teaches exactly this
check, so a pointer between the two might do the job on its own.

Start in basics/pda-rent-payer at the create_new_account accounts struct, then compare the authority guidance in basics/checking-accounts. Add only the agreed explanatory comment or cross-reference, preserving the example’s intentionally unrestricted behavior; done means the caller-check limitation and safer real-world alternatives are clear to readers.